JAD session: Joint application development:JAD (Joint Application Development) is a methodologythat involves the client or end user in the design and development of an application, through asuccession of collaborative workshops called JAD sessionsThe purpose of JAD is to bring together the technical/creative team and the businesscommunity in a structured workshop setting to extract consensus based softwarerequirements. 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 usesminimal planning in favor of rapid prototyping. The "planning" of software developed using RAD isinterleaved with writing the software itself. The lack of extensive pre-planning generally allows softwareto be written much faster, and makes it easier to change requirements.Rapid Application Development (RAD) is a process that speeds the delivery offunctionality to end-users by segmenting software into pieces for delivery rather thandelivering all of the software functionality in one large implementation.It is an iterative process utilizing a spiral methodology and is also customer driven followingan evolutionary process using continuous application engineering in a time-boxed fashionwith a dedicated professional team. The goal of the iterative approach is to reduce the timebetween requests and delivery of Business Application Software. Some of the primarycharacteristics 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
BRD stands for Business requirement document whatbusinessanalysts prepare based on client requirement.Functional requirement document is mainly technicaldocument or a high level design what project managersprepare.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 behandled by the solution. These are typically defined by the client but could also be defined by theBA. In my company we have written some BRDs.FRD is the Functional Requirements doc. These are requirements that are written based on theBRD. 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 ofthe how (design) in an FRD. But a testor should be able to look at a FRD and be able to figureout how to test that requirement.BRS is Business Requirement document It contains brief description about the applicationFrs is Functional Requirement Specification It contains all the functionalities in detailFRD: It contains modules in depth, with the help ofwireframes, process flow, UML, screenshots or whatever itneeds to explain to clientHow 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 specifyis, solution of the problem. Specify thorugly business problem and explain solution for the same.Business requirement documents does not necessarrily contains solution part, functional requirementmay contain it how end user wants the system to perform. Dont forget to add non-functionalrequirements same doc.Following is the instance of Business Requirement, Functional Requirement and Non-FunctionalRequirement.
Business Requirements :- sales order is made against customers purchase order. Sales order is given forapproval to upper authorityFunctional requirement:- Sales order shall be made with reference from Purchase order and it should beapproved from upper authority.Non-Functional Requirement:- Sales order should be in proper format (Specify format) and six copy ofsales 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 projectmanagement that describes the stages involved in an information systemdevelopment project, from an initial feasibility study through maintenance of thecompleted application.Various SDLC methodologies have been developed to guide the processes involved,including the waterfall model (which was the original SDLC method); rapidapplication development (RAD); joint application development (JAD); the fountainmodel; 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 anyapplication, and is usually done in parallel with the development process. Somemethods work better for specific types of projects, but in the final analysis, themost important factor for the success of a project may be how closely the particularplan was followed.
Use CasesUse cases model a dialogue between an actor and the system. They represent thefunctionality provided by the system; that is, what capabilities will be provided toan actor by the system. The collection of use cases for a system constitute all thedefined ways the system may be used.The formal definition for a use case is: A use case is a sequence of transactionsperformed by a system that yields a measurable result of valuesfor 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?
ACTIVITY DIAGRAMSSimilar to a flow chart, Activity Diagrams describe the sequencing of activities. Theyare actually a variant of the State Diagram. Like State Diagrams, the starting pointis indicated with a large black dot. The horizontal black lines indicate where theobject may take one of several different paths of action. Activity Diagrams areespecially useful for objects which contain a lot of complex logic that you wish toclearly present.SEQUENCE DIAGRAMSInteraction Diagrams show how groups of objects collaborate in some behavior.Sequence Diagrams are the most common type of Interaction Diagram, and show aninstance of an object and the ‘life’ of that object. In addition, the interaction betweenobjects is shown.Positive Test Case: To check if the application or system behaves as expected or as designed, when anyoperation is performed.Negative Test Case: Perform an unusual activity that is not defined nor that lets the system behave in aregular manner, and check what happens with the application.