Analysis Concepts And Principles


Introduction to Requirement Analysis

Complete understanding of software requirements is essential to the sucess of a software development effort

You could have a perfect program that does not do whatever the user wanted

Requirement analysis is a process of discovery, refinement, modeling and specification

Models of the required data, information and control flow, and operational behavior are created

Customer as inputer for functions and performance expectation; Developer as consultant and problem solver


Requirement Activities

Requirement understanding

Interview with users

Reading requirement documents

Inspection of requirement documents


Feasibility study

Project planning

User interface prototyping and testing

Test case generation



Verification and validation of specifications


Using FAST As Kick-Off Meeting

Facilitated Application Specification Techniques (FAST)

Team-oriented approach

Done in early stages of analysis and specification

Predominantly by the information systems community


Representatives from marketing, software and hardware engineering, manufacturing, etc

An outsider facilitator is to be used (More neutral and objective)

Different variations exist but the essence is the same

A common variations is to add DOMAIN EXPERT(S)

One or more role can be overlap



What/Who are Domain Experts

Software development is only a part of system development, and software requirement will not start until system design is completed.

The domain expert keeps on creating solutions when he gave the requirements

The requirements was being decomposed at the same time the solution was being decomposed.

It is possible to derive two hierarchies, one for the problem domain, the other solution domain.


Requirement Analysis by Analysts

After the FAST type meeting to collect information and requirement, We have to do analysis

Observing an analysts and a customer

The analyst followed an iterative process to capture and specify user requirements.

Four separate activities

Analysis -- recognition of relationships between "processes" and "things" in the client’s world.

Synthesis -- construction and modification of relationships between object model and the state transition model (STD).

Internal completeness and consistency -- determining C & C of the relationships between object model and the STD, and between "things" and "processes".

External completeness and consistency -- determining C & C between the "things" and the object model, and the "process" and the STD.


Analysis Cycle of Requirement Analysts

The analyst started with analysis activities and did not finish them until it reaches the 3/4 of the process.

The analyst started the synthesis activities at 1/4 time, and continued this kind of activities until the end of the process.

The analyst did the internal C&C while he did the synthesis.

The analyst started the external C&C at about the middle of the process and this kind of activities was the main actions at the end of process.


Object-Oriented Analysis

The analyst always thinks in term of objects and processes at the same time.

The analysis technique provide different degree of support -- strong on analysis and internal C&C, but weak on synthesis and external C&C.

However, in general, object-oriented analysis provides weak support -- most important decisions and actions still must be carried out manually.

I. A. Zualkernan, W. T. Tsai, A. Jemie, I. C. Wen and J. M. Drake, "Object-Oriented Analysis as Design: A Case Study", International Journal on Software Engineering and Knowledge Engineering, Vol. 2, No. 4, 1992, pp. 489-521.


Six Tasks of Analysis by A Davis

The following is the What is Important List

The requirement documents must be easy to read, understand and modify. Thus it must be written in a natural languages such as English and must be rather graphical (e.g Using Rational Rose).

The requirement documents for industrial projects are often large, thus it must support decomposition, abstraction and traceability.

Davis did not mention two important activities -- internal and external completeness and consistency. Internal completeness and consistency are best supported if the requirements are machine processable.

External validation are best supported if the specification can be understood by end users -- such as physicians, customers, managers, and even children.


What should be in a Requirement Specification

General description - application characteristics, definitions and acronyms, intended users, references, overview

Functional description

Database description - data structure diagrams, data dictionary

Performance - number of users, memory size, disk space, response time, workload and throughput

Output description

Design constraints - software, hardware and implementation


What should be in our Class Project


Tools we Need

Some OO Programming Language - Java

Some design tools - Rose from (Try this EARLY as a team)


Evaluation Criteria of Analysis Techniques

Problem Perspective

capture Data, transformation and control

visualize all perspective at a global level

focus on problems rather than implementation or design

Handle Large Problems

Model provides





All these analysis can be done using Rose


Why Process, Verification and Configuration Control

Process provides

Criteria for identifying partitions

Support for incremental analysis

Problem scope bounding

Analysis completion criteria

Verification and Validation

Support for peer, expert and customer review

Support for prototyping

Trace analysis components to the user requirement

Internal completeness and consistency

External completeness and consistency

Configuration Control

Manage configuration items

Support for standard products (for example 2167A)