Just in time Analysis - WTF!?!

Just-in-Time Requirements Analysis is the antithesis of
traditional analysis. Where in traditional development you strive to understand and define everything. Within JITRA you attempt to define just enough to satisfy planning and development.

It is a discipline that fits well with an Agile development process such as  Scrum. Focus shifts from defining everything to the last and final detail and shifts to ensuring that you have sufficient information to precede with the next phase of development. It is intended that requirements are only analysed as they are identified by the business as objectives or deliverables.

As agile processes generally follow a process of continuous revision and refinement; JITRA defines a process where requirements are continuously analysed and defined throughout the life cycle of a project. The important difference between JITRA and Waterfall Analysis is that the requirements are only analysed and defined when they are needed and only at the level of detail required.

So you don't sit specifying features that may never be requested by the business. Instead you focus on the next elements that are actually needed.

• The key points of JITRA that distingish it from other analysis methodologies are:
• Requirements aren’t analyzed or defined until they are needed.
  Only a small initial investment in analysis is required at the start.
• Actual development is allowed to begin with partial requirements.
• Analysis and requirements definition contiues throughout the project.
• Requirements are continuously refined as the project moves on, as stake holders see features and understand the problems they are attempting to solve.
• Change is expected and should be easy to incorporate into requirements.
• Analysis tasks compliment the agile or scrum planning process.

What are the benefits of such a process?

While performing waterfall analysis you may find your self having to speculate on system uses and potential pitfalls. Because JITRA has the paradym of not only defining it when it is needed, you perform your analysis and create the definition closer to when it is needed. This ensures that the analysis benefits from all information revealed by previous development work and stake holder feed back.
As the process complements Agile executives know that they are getting a return on their investment as the analysis feeds the development which delivers a business benefit.

What is a JITRA process?
The process is simple and if you are engaged in an agile development you may discover that you are already doing JITRA you simply dis not have a label for it.
The process starts at the highest levels of system abstraction and requirements, which will be continuously refined over the life cycle of the project. The analyst along with the stake holders must prioritise the most important features for analysis first. When the features are analysed it is always ONLY to the level of detail which meets the current requirements of the project - no more , no less.
For instance for a system that is completely new then sufficient analysis must be performed to specify, describe and understand the problem. With stake-holders informed and high level features of a system understood further analysis may be performed which answers questions specific to the first phase of the project and outlines a path for further phases.

JITRA defines four major analysis activities:
• Initial Analysis
• Feature Set Analysis
• Story Analysis
• After-action Analysis
These activities are performed continuously throughout a project’s life cycle, and may over lap each other in scope and detail.

Initial Analysis
The Initial Analysis activity is performed at the start of a new unit of work. This unit may be an individual system, a system of systems, a subordinate subsystem, or individual subsystem components. The purpose of this activity is to broadly define the scope for the work ahead and to specify an initial set of features, functions, and capabilities required for the specified unit of work. This may take a few hours or considerably longer depending on the overall size of the unit of work. The important point to stress is that no more analysis is performed than is actually needed to allow follow-on-activities to proceed. This doesn’t have to be a detailed understanding, but as a minimum the team must have a reasonable knowledge so that there can be an expectation of success if the project moves forward.
The final task of Initial Analysis is to define a generalized list of things the new system needs to do. This list might be a simple bullet list, or it might be detailed in one or more high-level Stories.
At the top-level, a unit of work may specify a system of systems. Initial Analysis is performed at the top level and then the unit of work is partitioned into one or more subordinate units of work.
This hierarchical decomposition is recursive and may continue down any number of levels. At each level an initial analysis is performed and the unit of work is either partitioned into subordinate units of work, or Initial Analysis is completed and Feature Set Analysis is begun.
BUT no more analysis than is required to precede is performed.

The output  of this process may be a formal document or the analysis may be communicated as a list, or it may be built into one or more high-level User Stories.

Feature Set Analysis
Feature Set Analysis (FSA) is performed continuously throughout the life cycle of a project. It’s purpose to build User Stories that feed into iteration planning and into individual iteration development. Most of the analysis effort on any project is performed as part of FSA, and it is the heart of the JITRA process.
At the start of FSA, all of the features, functions, and capabilities that have not yet been implemented (or which have only been partially implemented) are reviewed and prioritized by the Requirements
Stakeholders. This process allows stakeholders – and not developers - to identify what parts of
the system get the most focus, and always ensures that the most important part of the system will be analysed and developed next.

The output of FSA are groups of User Stories within the project backlog. These User Stories should be detailed enough to allow follow-on iteration planning, yet they do not have to be detailed enough to implement. In a some cases, the anlyst may discover that the selected Feature Set is too big to fit into a few iterations (sprints). In these situations the analyst's focus is applied to the highest priority
items (as identified by the stake holders) first, and return the unanalyzed items to the list of
unimplemented features, functions, and capabilities.
These items will then be addressed in follow-on Feature



Add further notes: start p140
http://cf.agilealliance.org/articles/system/article/file/1007/file.pdf