The following requirements artifacts represent the most common deliverables created in a Joint Requirements Planning (JRP/JAD) session. Many other business analysis deliverables can be created depending on the needs of the project. One of the major goals of the pre-session is to select which deliverables (business requirements artifacts) are appropriate for your project. Typically, the selected deliverables will be combined into an agreed upon requirements definition document (RDD — see sample TOC) or a Request for Proposal (RFP - see sample TOC) document.
A Business Process Model is a picture of how information technology supports the various business processes within your organization. It serves to define scope, validate requirements, evaluate potential “Quick Fixes”, and maintain continuity of development across multiple projects. Because it is a picture instead of words, you can recognize dimensions of the system that are not otherwise visible. The two most popular forms of business process models are data flow diagrams and swimlane diagrams. Often, the business processes that supported the business in the past fail to meet current business needs and need to be changed. For that reason, it is not uncommon to need an “as-is” model showing the current workflow and a “to-be” model showing the desired future workflow.
A Business Data Model depicts the structure of information that your organization uses independent of the underlying technology. Whether your organization uses mainframe, client/server or Intranet/Internet open architecture, the business data it needs are relatively consistent. Since data is more stable than processes (see above), it usually suffices to produce a single business data model that depicts the future structure of the data.
A list of prioritized Business Requirement Statements represents what the business community needs from IT. These requirement statements describe the solution in natural language (i.e., English) and are commonly decomposed into Functional, Informational, Behavioral, and Constraints. The decomposed requirement fragments are or become the steps in a use case, business data usage, and/or business rules.
Our JRP/JAD session facilitation teams create your Requirements Document with your selected deliverables in an interactive session working with your subject matter experts and business / system analysts. Click here for a detailed description how this phenomenally time–saving technique works.
A Use Case Diagram shows people and applications that are outside the scope of your project as “Actors” and use cases as ovals. If the use case diagram is a context diagram, there will typically be only one use case representing the entire application as being in scope. More detailed use case diagrams depict a varying number of use cases with the actors involved and potentially “includes” and “extends” relationships between the use cases.
A Use Case Narrative is the documentation of the interactions between one or more actors and your solution or application. It shows the steps involved in the interaction (separated into the basic path, alternative paths, and exception paths) that can be executed to achieve a specified goal or objective. There are a wide range of use case templates available on the web and whereas nearly all agree on the paths, the remaining sections of the document vary widely depending on the types of application they are designed to support and the opinions of the individual authors as to what should be represented.
Quick Fixes are recommended short term, stopgap solutions based on the evaluation of the existing situation. They are usually developed based on the results of problem analysis.
A Business Problem Statement is the results of problem analysis in which a list of problems, symptoms, proposed solutions, and extraneous facts are analyzed to identify the “real” problem. This form of problem analysis a minimalist approach to “root cause analysis” which is a much more rigorous and structured method that we recommend only if identifying the core business problem is a high priority and less stringent methods fail.
A Requirements Traceability Matrix shows how the individual requirements relate to other artifacts, i.e., other requirements, use cases, business processes, data entities, etc. Its primary purpose is to facilitate impact analysis in the event of changing requirements. It is also used to illustrate where individual requirements are implemented in the delivered application.
Is your project a good candidate for JRP/JAD?
Contact us for a free consultation (866) 584-2075.