What is jad_session
- 1. JAD session: Joint application development:JAD (Joint Application Development) is a methodology that involves the client or end user in the design and development of an application, through a succession of collaborative workshops called JAD sessions The purpose of JAD is to bring together the technical/creative team and the business community in a structured workshop setting to extract consensus based software requirements. 1 It brings together business area people (users) and IT (Information Technology) professionals in a highly focused workshop. 2 JAD participants typically include: oFacilitator – facilitates discussions, enforces rules oEnd users – 3 to 5, attend all sessions oDevelopers – 2 or 3, question for clarity oTie Breaker – senior manager. Breaks end user ties, usually doesn’t attend oObservers – 2 or 3, do not speak oSubject Matter Experts – limited number for understanding business & technology 3 Advantages: oShortening of the time. oImproves the quality of the final product by focusing on the up-front portion of the development lifecycle. oReducing the likelihood of errors that are expensive to correct later on. 4 A JAD session is a scheduled, formal workshop to create deliverables to the desired level of completeness in the shortest reasonable time. RAD :Rapid application development (R.A.D) is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. Rapid Application Development (RAD) is a process that speeds the delivery of functionality to end-users by segmenting software into pieces for delivery rather than delivering all of the software functionality in one large implementation. It is an iterative process utilizing a spiral methodology and is also customer driven following an evolutionary process using continuous application engineering in a time-boxed fashion with a dedicated professional team. The goal of the iterative approach is to reduce the time between requests and delivery of Business Application Software. Some of the primary characteristics of RAD projects are: There is a strict deadline for basic functionality Projects can be released in increments Techniques such as time-boxing, dedicated teams and focus sessions are used Business users are involved throughout the project and JAD is used Total project time is usually 3 - 6 months
- 2. BRD stands for Business requirement document what business analysts prepare based on client requirement. Functional requirement document is mainly technical document or a high level design what project managers prepare. BRD explains the "What" aspect of the Requirements i.e what is required? FRD explains the "How"aspect of the Requirements i.e "How" the "What" can be achieved. BRD is Business requirements doc, this is usually high level needs that the client expects to be handled by the solution. These are typically defined by the client but could also be defined by the BA. In my company we have written some BRDs. FRD is the Functional Requirements doc. These are requirements that are written based on the BRD. Through the traceability the FRD can be traced to one or more BRD and vice versa. FRD is something that must be testable. There is a fine line that you do not get into too much of the how (design) in an FRD. But a testor should be able to look at a FRD and be able to figure out how to test that requirement. BRS is Business Requirement document It contains brief description about the application Frs is Functional Requirement Specification It contains all the functionalities in detail FRD: It contains modules in depth, with the help of wireframes, process flow, UML, screenshots or whatever it needs to explain to client How would you transform business requirements to functional requirements? while preparing Business requirements documents you mention why you need to bulit a system, i.e. problem statement. What you need to do while creating functional requirements is you have to specify is, solution of the problem. Specify thorugly business problem and explain solution for the same. Business requirement documents does not necessarrily contains solution part, functional requirement may contain it how end user wants the system to perform. Dont forget to add non-functional requirements same doc. Following is the instance of Business Requirement, Functional Requirement and Non-Functional Requirement.
- 3. Business Requirements :- sales order is made against customers purchase order. Sales order is given for approval to upper authority Functional requirement:- Sales order shall be made with reference from Purchase order and it should be approved from upper authority. Non-Functional Requirement:- Sales order should be in proper format (Specify format) and six copy of sales order should be printed from printer in 1 minute. Systems Development Life Cycle (SDLC) The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
- 4. Use Cases Use cases model a dialogue between an actor and the system. They represent the functionality provided by the system; that is, what capabilities will be provided to an actor by the system. The collection of use cases for a system constitute all the defined ways the system may be used. The formal definition for a use case is: A use case is a sequence of transactions performed by a system that yields a measurable result of values for a particular actor. The following questions may be used to help identify the use cases for a system: What are the tasks of each actor? Will any actor create, store, change, remove, or read information in the system? What use case will create, store, change, remove, or read this information? Will any actor need to inform the system about sudden, external changes? Does any actor need to be informed about certain occurrences in the system? What use cases will support and maintain the system? Can all functional requirements be performed by the use cases?
- 5. ACTIVITY DIAGRAMS Similar to a flow chart, Activity Diagrams describe the sequencing of activities. They are actually a variant of the State Diagram. Like State Diagrams, the starting point is indicated with a large black dot. The horizontal black lines indicate where the object may take one of several different paths of action. Activity Diagrams are especially useful for objects which contain a lot of complex logic that you wish to clearly present. SEQUENCE DIAGRAMS Interaction Diagrams show how groups of objects collaborate in some behavior. Sequence Diagrams are the most common type of Interaction Diagram, and show an instance of an object and the ‘life’ of that object. In addition, the interaction between objects is shown. Positive Test Case: To check if the application or system behaves as expected or as designed, when any operation is performed. Negative Test Case: Perform an unusual activity that is not defined nor that lets the system behave in a regular manner, and check what happens with the application.