Saturday, January 28, 2017

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

Although data flow-oriented modeling is perceived as an outdated technique by some software engineers, it continues to be one of the most widely used requirements analysis notations in use today. 

Although the data flow diagram (DFD) and related diagrams and information are not a formal part of UML, they can be used to complement UML diagrams and provide additional insight into system requirements and flow.


The DFD takes an input-process-output view of a system. That is, data objects flow into the software, are transformed by processing elements, and resultant data objects flow out of the software.


Data objects are represented by labeled arrows, and transformations are represented by circles (also called bubbles).  


The DFD is presented in a hierarchical fashion.

That is, the first data flow model (sometimes called a level 0 DFD or context diagram) represents the system as a whole.

Subsequent data flow diagrams refine the context diagram, providing increasing detail with each subsequent level.


Creating a Data Flow Model

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

The data flow diagram enables you to develop models of the information domain and functional domain.

 As the DFD is refined into greater levels of detail, you perform an implicit functional decomposition of the system.

Simple guidelines  the derivation of a data flow diagram:-

(1) the level 0 data flow diagram should depict the software/system as a single bubble.
(2) primary input and output should be carefully noted.
(3) refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level.
(4) all arrows and bubbles should be labeled with meaningful names.
(5) information flow continuity must be maintained from level to level.
(6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram.

The refinement of DFDs continues until each bubble performs a simple function.

That is, until the process represented by the bubble performs a function that would be easily implemented as a program component. called cohesion.

Control Flow Model

For some types of applications, the data model and the data flow diagram are all that is necessary to obtain meaningful insight into software requirements.

Such applications require the use of control flow modeling in addition to data flow modeling.

I have already noted that an event or control item is implemented as a Boolean value.

The following guidelines are for select potential candidate events:

·   List all sensors that are “read” by the software.
·   List all interrupt conditions.
·   List all “switches” that are actuated by an operator. 
·   List all data conditions.
·  Recalling the noun/verb parse that was applied to the processing narrative,     review all “control items” as possible control specification inputs/outputs.
·   Describe the behavior of a system by identifying its states, identify how each state is reached, and define the transitions between states.
·  Focus on possible omissions—a very common error in specifying control; for example, ask: “Is there any other way I can get to this state or exit from it?”

The Control Specification

A control specification (CSPEC) represents the behavior of the system in two different ways.

The CSPEC contains a state diagram that is a sequential specification of behavior. It can also contain a program activation table a combinatorial specification of behavior.

A somewhat different mode of behavioral representation is the process activation table. The PAT represents information contained in the state diagram in the context of processes, not states.

That is, the table indicates which processes (bubbles) in the flow model will be invoked when an event occurs.

The PAT can be used as a guide for a designer who must build an executive that controls the processes represented at this level.

The CSPEC describes the behavior of the system, but it gives us no information about the inner working of the processes that are activated as a result of this behavior.

The Process Specification

The process specification (PSPEC) is used to describe all flow model processes that appear at the final level of refinement.

The content of the process specification can include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, or UML activity diagrams.

By providing a PSPEC to accompany each bubble in the flow model, you can create a “mini-spec” that serves as a guide for design of the software component that will implement the bubble. 

Monday, January 9, 2017

Requirements Modeling Strategies | Structured Analysis | Object-Oriented Analysis

Requirements Modeling Strategies | Structured Analysis

One view of requirements modeling, called structured analysis, considers data and the processes that transform the data as separate entities.

Data objects are modeled in a way that defines their attributes and relationships.

Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system.

A second approach to analysis modeled, called object-oriented analysis, focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements.

The question is not which is best, but rather, what combination of representations will provide stakeholders with the best model of software requirements and the most effective bridge to software design.

Validating Requirements | When I review requirements, what questions should I ask?

Validating Requirements | When I review requirements, what questions should I ask?

As each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity.

The requirements represented by the model are prioritized by the stakeholders and grouped within requirements packages that will be implemented as software increments.

Following questions:

Is each requirement consistent with the overall objectives for the system/product?

Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

Is each requirement bounded and unambiguous?

Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

Do any requirements conflict with other requirements?

Is each requirement achievable in the technical environment that will house the system or product?

Is each requirement testable, once implemented?

Does the requirements model properly reflect the information, function, and behavior of the system to be built?

Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

• Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?

Follow by Email