Software Engineering Lecture 11: System Analysis

Today’s Topics l Requirements Analysis & Elicitation l Modeling the Problem Domain l Prototyping l Structured Analysis Models

Analysis: A Bridge Between System Engineering & Software Design [From SEPA/5e]

Interview Questions l “Who is requesting the work?” l “Who will use the solution?” l “Desired economic benefits?” l “Another source for solutions?” l “What’s ‘good’ output?” l “What problems are addressed?” l “Environment of use?” l “Special issues or constraints?” l Meta-questions re: process

Facilitated Application-Specific Techniques (FAST) l Conduct meetings at neutral site l Rules for meetings established l Formal agenda, informal discussion l “Facilitator” controls meeting l “Definition mechanism” agreed upon by participants

FAST [3] l Goals: identify problem propose elements of a solution negotiate different approaches specify preliminary set of requirements atmosphere: goal-directed

Quality Function Deployment (QFD) l Normal Requirements (explicitly discussed) l Expected Requirements (easy install, good doc) l Exciting Requirements (unexpected, welcome) l Prioritize, document, and discuss with customer

Modeling the Information Domain l Data ( numbers, text, etc.) l Control ( events) l Information Content (objects, attributes) l Information Flow (changes to data/control during execution) l Information Structure (internal data and control, relations, etc.)

[From SEPA/5e] Information Flow and Transformation

Modeling l Focus on “what”, not “how” l Functional models (HIPO to algorithm identification) l Behavioral models (program state & changes thereto) l Models provide: tool for understanding focal point for review foundation for design

Partitioning l Decompose information, functional, and behavioral domains into subproblems l Vertical: expose more detail l Horizontal: decompose into subcomponents

[From SEPA/5e] Horizontal Partitioning functional decomposition

[From SEPA/5e] Vertical Partitioning exposes detail

Essential vs. Implementation View l Essential view presents the functions to be accomplished, without implementation details l Implementation view presents “real-world” manifestation of essential elements “current mode of operation” (not a proposed design!)

Prototyping l Construct/analyze a prototype: to validate requirements to show feasibility of solution l Throwaway: discarded before full development l Evolutionary: prototype is first version of finished system

[From SEPA/5e] The Prototyping Decision Process

Structured Analysis Model [From SEPA/5e]

Structured Analysis l Data Dictionary descriptions of all data objects l Entity-Relationship Diagram depicts relations between objects l Data Flow Diagram how data are transformed functions that transform them

Structured Analysis [2] l State-Transition Diagram states: modes of behavior transitions: trigger state change l Data Object Description note attributes of each object l Process Specification describe each process in DFD l Control Specification describe each state/transition in STD

[From SEPA/5e] Data Objects, Attributes, Relationships

Tabular Representation of Data Objects [From SEPA/5e]

Relationships

[From SEPA/5e] Cardinality and Modality

[From SEPA/5e] Simple ERD, Data Object Table

[From SEPA/5e] Expanded ERD

[From SEPA/5e] Data Object Type Hierarchy

[From SEPA/5e] Associative Data Objects

Information Flow Model [From SEPA/5e] data flow diagram

[From SEPA/5e] Behavioral Model control flow diagram

[From SEPA/5e] State- Transition Diagram

Specifications l Control Specification state-transition diagram program activation table: “a combinatorial specification of behavior” l Process Specification narrative text pseudocode or program design language (PDL)

[From SEPA/5e] Program Activation Table which processes are invoked when an event occurs?

Specifications [2] l Data Dictionary (for each object): Name & Aliases Where Used / How Used Content Description Supplementary Information data types, default values, restrictions, limitations, etc.

Questions?