Post on 04-Jan-2016
© 2000 Franz Kurfess Requirements Management 1
CSC 205: Software Engineering ICSC 205: Software Engineering I
Dr. Franz J. Kurfess
Computer Science Department
Cal Poly
© 2000 Franz Kurfess Requirements Management 2
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
© 2000 Franz Kurfess Requirements Management 3
Chapter OverviewRequirements Management
Chapter OverviewRequirements Management
Motivation Objectives Evaluation Criteria Information Flow Models Data Dictionary
Data Flow Diagrams Important Concepts and
Terms Chapter Summary
© 2000 Franz Kurfess Requirements Management 4
LogisticsLogistics
Introductions Course Materials
textbook handouts Web page CourseInfo/Blackboard System
Term Project Lab and Homework Assignments Exams Grading
© 2000 Franz Kurfess Requirements Management 5
Bridge-InBridge-In
© 2000 Franz Kurfess Requirements Management 6
Pre-TestPre-Test
© 2000 Franz Kurfess Requirements Management 7
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
© 2000 Franz Kurfess Requirements Management 8
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
© 2000 Franz Kurfess Requirements Management 10
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]
© 2000 Franz Kurfess Requirements Management 11
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]
© 2000 Franz Kurfess Requirements Management 12
Requirements AnalysisRequirements Analysis
[Kearns 00]
© 2000 Franz Kurfess Requirements Management 13
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]
© 2000 Franz Kurfess Requirements Management 14
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]
© 2000 Franz Kurfess Requirements Management 15
AnalyzeAnalyze
classify requirementsidentify system boundariesuse checklistsidentify interactionsassess risksprioritize
[Kearns 00]
© 2000 Franz Kurfess Requirements Management 16
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]
© 2000 Franz Kurfess Requirements Management 17
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]
© 2000 Franz Kurfess Requirements Management 18
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]
© 2000 Franz Kurfess Requirements Management 19
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]
© 2000 Franz Kurfess Requirements Management 20
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]
© 2000 Franz Kurfess Requirements Management 21
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]
© 2000 Franz Kurfess Requirements Management 22
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]
© 2000 Franz Kurfess Requirements Management 23
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]
© 2000 Franz Kurfess Requirements Management 24
Why Were DFDs Developed?
controlling complexityisolate flows and processinguncover structure of information flowcommunication/summarization toolnot tied to existing processorganizational separation of skills
[Kearns 00]
© 2000 Franz Kurfess Requirements Management 25
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]
© 2000 Franz Kurfess Requirements Management 28
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]
© 2000 Franz Kurfess Requirements Management 29
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]
© 2000 Franz Kurfess Requirements Management 30
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]
© 2000 Franz Kurfess Requirements Management 31
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]
© 2000 Franz Kurfess Requirements Management 32
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
© 2000 Franz Kurfess Requirements Management 34
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]
© 2000 Franz Kurfess Requirements Management 35
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]
© 2000 Franz Kurfess Requirements Management 36
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]
© 2000 Franz Kurfess Requirements Management 37
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]
© 2000 Franz Kurfess Requirements Management 38
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]
© 2000 Franz Kurfess Requirements Management 39
[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]
© 2000 Franz Kurfess Requirements Management 40
Decompose Process Order Decompose Process Order
[Invoice]
[Order Confirmation]
[New Order] [Product Info]
[Old Customer][New Customer]
[Customer and Product Info]
Customer
Customers Orders Inventory
[Kearns 00]
© 2000 Franz Kurfess Requirements Management 41
Order to be Shipped
Order to be Verified
[Invoice]
[Order Confirmation]
[New Order] [Product Info][Old Customer][New Customer]
[Customer and Product Info]
Customer
Customers Orders Inventory
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]
© 2000 Franz Kurfess Requirements Management 42
Add Synonyms for ReadabilityAdd Synonyms for Readability
[Invoice]
[Order Confirmation]
[Product Info][New Order]
[New Customer]
[Old Customer]
[Customer and Product Info]
Order to be Shipped
Order to be Verified
Customer
Customers Orders Inventory
1.1
Take Order
1.2Verify Order
1.3Make
Shipment
Customer
Customer
[Kearns 00]
© 2000 Franz Kurfess Requirements Management 43
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 Confirmation]
[Customer and Product Info]
Order to be Shipped
Order to be Verified
Customer
Customers Orders Inventory
1.1
Take Order
1.2
Verify Order
1.3
Make Shipment
Customer
[Kearns 00]
© 2000 Franz Kurfess Requirements Management 45
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]
© 2000 Franz Kurfess Requirements Management 47
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]
© 2000 Franz Kurfess Requirements Management 48
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]
© 2000 Franz Kurfess Requirements Management 49
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]
© 2000 Franz Kurfess Requirements Management 50
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]
© 2000 Franz Kurfess Requirements Management 51
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]
© 2000 Franz Kurfess Requirements Management 52
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]
© 2000 Franz Kurfess Requirements Management 53
Ethnography and PrototypingEthnographicanalysisDebriefingmeetingsFocusedethnographyPrototypeevaluationGeneric systemdevelopment Systemprotoyping[Sommerville 01]
© 2000 Franz Kurfess Requirements Management 54
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]
© 2000 Franz Kurfess Requirements Management 60
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
© 2000 Franz Kurfess Requirements Management 61
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]
© 2000 Franz Kurfess Requirements Management 62
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]
© 2000 Franz Kurfess Requirements Management 63
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]
© 2000 Franz Kurfess Requirements Management 64
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]
© 2000 Franz Kurfess Requirements Management 65
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]
© 2000 Franz Kurfess Requirements Management 66
Automated Consistency CheckingAutomated Consistency Checking
RequirementsdatabaseRequirementsanalyserRequirementsproblem reportRequirementsprocessorRequirementsin a formal language[Sommerville 01]
© 2000 Franz Kurfess Requirements Management 67
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]
© 2000 Franz Kurfess Requirements Management 68
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]
© 2000 Franz Kurfess Requirements Management 69
Requirements EvolutionChangedunderstandingof problemInitialunderstandingof problem ChangedrequirementsInitialrequirements Time[Sommerville 01]
© 2000 Franz Kurfess Requirements Management 70
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]
© 2000 Franz Kurfess Requirements Management 71
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]
© 2000 Franz Kurfess Requirements Management 72
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]
© 2000 Franz Kurfess Requirements Management 73
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]
© 2000 Franz Kurfess Requirements Management 74
A Traceability MatrixA Traceability Matrix
[Sommerville 01]
U: [row] utilizes [column] requirementR: other relationship
© 2000 Franz Kurfess Requirements Management 75
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]
© 2000 Franz Kurfess Requirements Management 76
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]
© 2000 Franz Kurfess Requirements Management 77
Requirements Change ManagementRequirements Change Management
ChangeimplementationChange analysisand costingProblem analysis andchange specificationIdentifiedproblem Revisedrequirements[Sommerville 01]
© 2000 Franz Kurfess Requirements Management 80
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
© 2000 Franz Kurfess Requirements Management 81
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 82