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. 

• It commits top executives to the software-planning process. JAD involves top executives from the beginning of a product's development. Early executive involvement shortens the product-approval cycle.

• It shortens the requirements-specification phase. JAD reduces the amount of time needed to gather requirements, which shortens the overall development cycle. This is particularly useful because requirements specification can be an essentially unbounded activity that adds weeks or months to a project's front end.
•  
• It eliminates features of questionable value. By eliminating questionable features and making the product smaller, JAD reduces development time.

• It helps to get requirements right the first time. Requirements analysts and end-users speak different languages, which means that the chances of them communicating effectively about software requirements are slim. JAD improves communication and eliminates costly rework resulting from mistaken requirements.

• It helps to get the user interface right the first time. Some products require extensive rework because end-users reject the product's user interface. JAD-design sessions focus on user-interface design. Because end-users are involved in those sessions, the user interface that's developed is usually ultimately acceptable to end-users.

• It reduces organizational infighting. Many projects are hobbled by conflicting objectives or hidden agendas. By bringing all the decision makers together to design the system, JAD brings these issues to light early in the project, when they can still be addressed effectively and before they've had time to do much damage.

 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

• Define, review and finalize Vision, Scope and Business Case for the project.
• Identify all high level use cases.
• Develop Use Case development guidelines and model. Develop prototype use cases using one of the key use cases based on the use case model.
• Develop and finalize the project plan and key project management artifacts – risk management plan, and change management plan.
• Identify, procure and install required development tools and hardware required to create development / prototyping environment.
• Define Application Architecture and develop a proof of concept to validate the architectural layers – User Interface, Business Logic Components, Application Programming Interface, OLTP Database and Data Warehouse.
• Staff project and communicate project roles and responsibilities.

Elaboration Phases

• Perform detailed analysis of application requirement.
• Establish a solid understanding of the most critical requirements.
• Evolve the requirements and use cases to the '80% point'
• Elaborate and validate application architecture to ensure that requirements are met.
• Eliminate high-priority risks via modeling and prototyping
• Demonstrate, to all project stakeholders, that the architecture supports the project vision and requirements.
• Review and refine project plan with a focus on construction phase tasks.

Construction Phase

• Detailed design and construction of the application – user interface, business logic component and database layers.
• Validate that the application meets the requirements.
• Achieve and maintain application quality targets.
• Test application components.
• Beta Application User documentation and Online Help developed.

Transition Phase

• Initial Product release.
• Application User Documentation and online help released.

What are software requirements? 

There are two types of software requirements.  

Functional Requirements: 

• Describe the functionality of ZIMS.
• Define the scope, boundaries and interfaces to related systems.
• Define the business rules that ZIMS must conform to.

  Non-Functional Requirements: 

• Describe the look and feel of the system.
• Define system usability, and the performance requirements.
• Describe the intended operating environment, maintainability, portability.
• Defines ZIMS system security.
• Describes cultural, political, legal and compliance requirements that ZIMS must conform to.

 Characteristics of Good Requirements are: 

• Complete – they very thoroughly describe ZIMS.
• Correct – they are accurate and true.
• Feasible – they can be accomplished and individual requirements do not contradict each other.
• Necessary – they are truly needed for ZIMS to meet business functionality.
• Prioritized – It’s important to be able to distinguish “absolutely necessary” from “nice to have”.
• Unambiguous – they are clear and cannot be misinterpreted.
• Verifiable – once implemented, it can be confirmed that ZIMS has met the requirement through observation and testing.

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:

• Facilitate visualization of ZIMS as the User Community wants it to be.
• Specify the structure and behavior of ZIMS.
• Use models as a template to guide the team in constructing ZIMS.
• Document the decisions that are made.
• Use a common language (UML – Unified Modeling Language) to facilitate communication and validation of the requirements and design of ZIMS.

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

 What is UML?

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