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 understanding
Interview with users
Reading requirement documents
Inspection of requirement documents
Prototyping
Feasibility study
Project planning
User interface prototyping and testing
Test case generation
Restructuring
Specifications
Verification and validation of specifications
Facilitated Application Specification Techniques (FAST)
Team-oriented approach
Done in early stages of analysis and specification
Predominantly by the information systems community
A meeting is conducted at a neutral site and attended by both developers and customers
Company rules for preparation and participation are established (Need to attened, with some research reading before)
An agenda is used to guide through all the important points to cover (can be formal or informal)
A "facilitator" (who can be a customer, a developer, or an outsider) controls the meeting
A "definition mechanism" is used which drop then all the definition or output (using pencil and paper or computer is used)
The goal is to IDENTIFY THE PROBLEM, PROPOSE ELEMENTS OF THE SOLUTION, NEGOTIATE ALTERNATIVE APPROACHES, and specifiy a preliminary set of solution requirements in an atomosphere that is conducive to the accomplishment of the goal
So, we have FACILITATOR, CUSTOMER(S), DEVELOPER(S), RECORDER
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
So, we might have FACILITATOR, CUSTOMER(S), DOMAIN EXPERT(S), DEVELOPER(S), RECORDER
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.
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.
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.
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.
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.
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
Some OO Programming Language - Java
Some design tools - Rose from www.rational.com (Try this EARLY as a team)
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
Partitioning
Decomposition
Abstraction
Integration
All these analysis can be done using Rose
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)