What is JAD? 

JAD stands for "Joint Application Development". JAD is a requirements-definition and software system design methodology in which stakeholders, subject matter experts (SME), end-users, software architects and developers attend intense off-site meetings to work out a system's details. JAD focuses on the business problem rather than technical details. It is most applicable to the development of business systems. It produces its savings by shortening the elapsed time required to gather a system's requirements and by gathering requirements better, thus reducing the number of costly, downstream requirements changes. Its success depends on effective leadership of the JAD sessions; on participation by key end-users, executives, and developers; and on achieving group synergy during JAD sessions. JAD works best when combined with an incremental-development lifecycle model such as RUP (Rational Unified Process).  

The focal point of the JAD process is a series of workshops that are attended by stakeholders, executives, SME’s, end-users, software architects and developers. JAD leverages group dynamics, extensive use of visual aids, documentation, prototypes and an organized, rational process to gather and define requirements in a short time. JAD is one of the most powerful requirements-specification practices yet developed, and it produces its savings in several ways. 


 What is RUP?

RUP stands for “Rational Unified Process”, a software development methodology from Rational (now part of IBM). RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development. The goals of each of the phases are:

Inception Phase

Elaboration Phases

Construction Phase

Transition Phase


What are software requirements? 

There are two types of software requirements.  

Functional Requirements: 

  Non-Functional Requirements: 

 Characteristics of Good Requirements are: 


What is Visual Modeling? 

Visual Modeling develops the ‘blue-print’ for building ZIMS based on the analysis and understanding of the requirements. It is a simplification of reality. Visual Modeling is used to achieve the following:

A number of documents and diagrams are used in UML based visual modeling to model various aspects ZIMS. The following table describes them.  


Document / Diagram


User community & Functionality

Use Cases

Who uses ZIMS and what goals can they achieve by using it?


Activity Diagrams

What is the flow of events in the business processes facilitated by ZIMS?


State Transition Diagrams

What happens during the lifetime of a ZIMS object? How do events trigger changes from one discrete state (Ex. an Animal is ‘On exhibit’) to another (Ex. an Animal is ‘Not On exhibit’)?


Class Diagrams

What kinds of entities (Animal, Enclosure, etc.) play a part in the business process facilitated by ZIMS,  how are they related, and what are the rules that govern them?


Object Diagrams

What does ZIMS look like at some specific moment in time?


Sequence Diagrams

How do objects interact with each other over time to achieve some goal?


Collaboration Diagrams

How do clusters of related objects interact to achieve some goal?


Component Diagrams

What are the physical components that make up ZIMS and how are they dependant on each other?


Deployment Diagrams

What hardware are the physical components of ZIMS deployed on and how do they communicate with each other?

 What is UML?

 UML stands for “Unified Modeling Language”, a general-purpose notational language for specifying, modeling and visualizing complex software.