Software Engineering
Lecture 11: System Analysis
Today’s Topics Requirements Analysis & Elicitation Modeling the Problem Domain Prototyping Structured Analysis Models
Analysis: A Bridge Between System Engineering & Software Design
[From SEPA/5e]
Interview Questions “Who is requesting the work?” “Who will use the solution?” “Desired economic benefits?” “Another source for solutions?” “What’s ‘good’ output?” “What problems are addressed?” “Environment of use?” “Special issues or constraints?” Meta-questions re: process
Facilitated Application-Specific Techniques (FAST)
Conduct meetings at neutral site Rules for meetings established Formal agenda, informal discussion “Facilitator” controls meeting “Definition mechanism” agreed upon by
participants
FAST [3]
Goals:• identify problem
• propose elements of a solution
• negotiate different approaches
• specify preliminary set of requirements
• atmosphere: goal-directed
Quality Function Deployment (QFD)
Normal Requirements(explicitly discussed)
Expected Requirements(easy install, good doc)
Exciting Requirements(unexpected, welcome)
Prioritize, document, and discuss with customer
Modeling the Information Domain
Data (numbers, text, etc.) Control (events) Information Content (objects, attributes) Information Flow
(changes to data/control during execution) Information Structure
(internal data and control, relations, etc.)
[From SEPA/5e]
Information Flow and Transformation
Modeling Focus on “what”, not “how” Functional models (HIPO to algorithm
identification) Behavioral models
(program state & changes thereto) Models provide:
• tool for understanding
• focal point for review
• foundation for design
Partitioning
Decompose information, functional, and behavioral domains into subproblems
Vertical: expose more detail Horizontal: decompose into subcomponents
[From SEPA/5e]
Horizontal Partitioning
• functional decomposition
[From SEPA/5e]
VerticalPartitioning
• exposes detail
Essential vs. Implementation View
Essential view• presents the functions to be accomplished, without
implementation details
Implementation view• presents “real-world” manifestation of essential elements
• “current mode of operation”(not a proposed design!)
Prototyping Construct/analyze a prototype:
• to validate requirements
• to show feasibility of solution
Throwaway: discarded before full development Evolutionary: prototype is first version of
finished system
[From SEPA/5e]
The Prototyping Decision Process
StructuredAnalysisModel
[From SEPA/5e]
Structured Analysis
Data Dictionary• descriptions of all data objects
Entity-Relationship Diagram • depicts relations between objects
Data Flow Diagram• how data are transformed
• functions that transform them
Structured Analysis [2] State-Transition Diagram
• states: modes of behavior
• transitions: trigger state change
Data Object Description• note attributes of each object
Process Specification• describe each process in DFD
Control Specification• describe each state/transition in STD
[Fro
m S
EPA
/5e]
Data Objects, Attributes, Relationships
Tabular Representation of Data Objects
[From SEPA/5e]
[Fro
m S
EPA
/5e]
Relationships
[Fro
m S
EPA
/5e]
Cardinality and Modality
[Fro
m S
EPA
/5e]
Simple ERD, Data Object Table
[Fro
m S
EPA
/5e]
ExpandedERD
[Fro
m S
EPA
/5e]
Data ObjectType Hierarchy
[Fro
m S
EPA
/5e]
AssociativeData Objects
Information Flow Model
[From SEPA/5e]• data flow diagram
[Fro
m S
EPA
/5e]
BehavioralModel
• control flow diagram
[Fro
m S
EPA
/5e]
State-TransitionDiagram
Specifications Control Specification
• state-transition diagram
• program activation table: “a combinatorial specification of behavior”
Process Specification• narrative text
• pseudocode or program design language (PDL)
[Fro
m S
EPA
/5e]
Program Activation Table
• which processes are invoked when an event occurs?
Specifications [2] Data Dictionary (for each object):
• Name & Aliases
• Where Used / How Used
• Content Description
• Supplementary Information• data types, default values, restrictions, limitations, etc.
Questions?
Top Related