My contemplations and diurnal novelties are publicized here

The structure of business analysis documents isn’t a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.

These are the main documents produced by a BA over the course of a project:

  • Current state analysis document
  • Project vision document
  • Solution vision document
  • Business requirements document
  • Business process design document
  • Use case model document
  • Use case specification document
  • System-wide requirements document
  • Solution glossary

The diagram below shows the attributes common to all documents:

Current State Analysis

Once a project has been mandated and the Project Initiation document (PID) is drafted, a business analyst can start to work on requirements gathering. In my experience the best way to tackle this task is to start from current state analysis. It helps understand the business need, primary pain points, business processes affected, the stakeholders involved in these processes, and so on.

The area of the current state analysis is illustrated below:

The main purpose of the analysis is to present the “AS IS” state: the existing business context, background, business functions and existing business processes, and finally stakeholders involved in these business processes. Depending on the project nature, some components of the underlying infrastructure can be included in the document as well.

A Current State Analysis document lists the key pain points within the identified business processes and tasks within them, and highlights the areas where a change is expected.

The last section of the document is about presenting recommendations. It recaps the key findings and lists the key changes expected. Any caveats should be presented here as well.

The content structure of the Current State Analysis document is presented below:

This document serves as a foundation or a reference point for other artifacts produced by a business analyst. The other documents will be discussed in the following articles.

Project Vision

The Project Vision is a document which is shared by a project manager and business analyst. They work together to outline the problem statement, determine the desired state, describe the criteria of business acceptance of the deliverables and how project success will be measured. The document contains a section with stakeholder analysis which shows all the parties involved along with their responsibilities and needs:

The business analyst adds the high level requirements which are within the scope of the project, and marks each requirement as compulsory or optional. To clearly define the project scope and avoid ambiguity, all out-of-scope requirements are also listed at the end of the section.

Based on the results of the current state analysis the business analyst describes the current business context, the key business processes and services used to support them. After that the required changes are mapped to the current business context. It can be a good idea to present this mapping as a diagram for easy communication of the proposed changes to the business stakeholders.

Solution Vision

Once the Project Vision document is approved, the preparation of the Solution Vision document starts.

First, the business analyst recaps the problem statement from the Project Vision artifact. The solution statement describes the target audience of the solution, what will be satisfied by the solution and what the key benefits will be. The statement of differentiation of the solution from possible alternative options is added as a conclusive point in positioning of the solution.

The document describes stakeholders within the target audience along with their roles using a RACI matrix.

The main part of a Solution Vision is a detailed section devoted to the solution capabilities comprised of both functional and non-functional features, with priorities given by the business stakeholders.

The next section presents the business context in its future “to be” state. It’s a good idea to include a a diagram illustrating the key changes and additions to the existing state, as well as a brief narrative to clarify the proposed changes.

Similarly to the Project Vision document, the features that are out of scope are clearly listedin the last section to make sure everyone is on the same page with regards to what will be implemented.

Business Requirements

This document focuses on providing details about the current processes and gives enough information to describe the business problem and how it fits into the scope of the project. This section reiterates the findings of the Current State Analysis document, however here they are aligned with the project objectives.

The business requirements that are going to be fulfilled by the solution are listed in the “In Scope” section. Business rules that apply to the described requirements are presented in a separate section. This approach simplifies the confirmation of the rules with business stakeholders. 
Any assumptions and dependencies identified in relation to the business requirements are to be listed in the appropriate section.
The proposed changes to stakeholder roles, new or modified business processes and business services that support them are presented in the last section.

Business Process Design

This document focuses on the scope of changes to business processes, providing details about the current business context, existing business processes, and stakeholders involved in these business processes.

It also describes the future state: the proposed business processes and the “to be” information environment. The new processes are accompanied with narratives to facilitate communication of the proposed changes to stakeholders and business end users. This “as is” section reiterates the findings of the Current State Analysis document, however here they are aligned with the changes to supporting business services.
Any assumptions and dependencies identified in relation to changes to the business processes are listed in the appropriate section.

Use Case Model

The Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful to describe the solution as a set of functional areas and group the scenarios per functional area. Such an approach allows to use this document more efficiently in communication with the business stakeholders as they can easily refer to the sections of their interest.

The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency of use, triggering events and the two possible outcomes – success and failure.
One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities which allows to establish traceability.
Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model document accordingly.

Use Case Specification

A Use Case Specification document presents more detailed information about the use cases in the Use Case Model document.

Each specification includes:

  • Brief use case overview
  • Reference to the functional area
  • Preconditions
  • Actors involved
  • Main flow
  • Alternative flows
  • Exception handling flows
  • Functional requirements for the solution
  • Traceability to the business requirements
  • Market or business rules applicable to the scenario
  • User interface, controls and data

System-Wide Requirements

This document is prepared when the Business Requirements, Use Case Model and Use Case Specifications are complete. The main purpose of the document is to present a “qualitative” side of the solution.

The “Load patterns” section is the most interesting as it illustrates how the solution is expected to be used during a business day. This information gives good insight into business requirements from the “non-functional” perspective and helps clarify the business requirements where required.As solutions are often based on information technology, some attention should be given to solution resilience. Disaster mitigation approaches and solution recovery requirements play a major role here.It is a rare case nowadays that a solution is completely new. The common practice is to integrate the solution into the existing business environment. The system-wide requirements document describes the interfaces with internal and external systems and solutions, the data flowing between them, its formats and data elements. Where the solution should interface with external systems, samples of data must be presented in appendices.Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring how the solution operates. These reports are listed in the last section of the document.

Solution Glossary

Business stakeholders often use terms and jargon in their communication. To get up to speed with this terminology (you can be quite new to it), the Solution Glossary document is used. It helps establish common terminology for the project team and key stakeholders, and for use within the solution. The structure of this document is simple:

It’s a good practice to divide the solution into functional areas. These functional areas serve as small knowledge domains for the stakeholders involved in the project. This document serves as a reference point for all the previously discussed documents.

Copied from :-

Recently I faced any issue where after restoring the database in mysql, auto increment values started from zero.

This started giving duplicated entry error. First I figured out the issue using this

SELECT AUTO_INCREMENT FROM information_schema.tables

WHERE table_schema=’mydb’ AND table_name=’mytablename’

Then I tried to resolve this using:-

UPDATE information_schema.tables


WHERE table_schema=’mydb’ AND table_name=’mytablename’

But got error mentioning:-

Access denied for user ‘root’@’localhost’ to database ‘information_schema’

I tried:-


will reset the auto_increment value to be the next value based on the highest existing value in the auto_increment column.



Run –> inetmgr –> enter –> click on App Pool  -> right-click on App –> set Application Pool Defaults –> just change everything with (seconds) to 600 instead of 90.

When you are debugging, IIS will not service any other requests until you are done stepping through your code. That includes the “ping” request that IIS sends to itself. Since IIS doesn’t hear back from itself, it decides to shut itself down, which promptly terminates your debugging.

The solution is to increase the Ping Maximum Response Time in the application pool settings from its default value of 90 seconds. Set it to something high enough that will give you enough time to debug your code (like maybe 600 seconds).

Microsoft has a long-winded write-up here, or you can just look at the pretty picture.

Edit: Others have suggested setting “Ping Enabled” to false. There are several reasons why I prefer to keep it in place, just with a larger interval, but the most important is that you will (most likely) have worker processing pinging enabled on production, and you should strive to develop and debug under a configuration that is as close to production as possible. If you do NOT have ping enabled on production, then by all means disable it locally as well.

Copied from:-

How to add externals in svn

I have a few projects in subversion using the same set of third party tools nant, bdd, mbunit etc. I’ve read its a good idea to put the tools into their own repository and include them in the other projects using an svn:external. The advantage this gives you is any changes you make to the external repository can be updated easily across all projects. Any hoose this is who to do it.

  1. Go to the root of the folder you want to add the externals too.
  2. Right click on the root folder of the project you want to add the external repository to and select TortoiseSVN –> Properties.   Note: This folder has to be a checked out subversion repository or you’ll not get the context menu! 
  3. You will now see the subversion properties dialog.
  4. Click the New.. button. You will now see the Add properties dialog.
  5. Select svn:externals from the property name drop down list.
  6. Enter the name you want to give to the external folder followed by the path to your tools repository in property value text area. 
    In the example above: tools svn://server/tools/trunk 
    Note: You can add more external repositories by simply adding more lines to the property value text area.
  7. Click Ok to add the property will now be listed in the properties dialog.
  8. Right click on the root folder and select SVN Update from the menu. Subversion will now pull down the files from the external repository and your done.

    Once you check this change in other people checking out from the repository will automatically get the externals folder. Also any changes to the external repository will be updated in this repository on any update. So in this case if I add a new tool or update one of the tools all repositories using this external repository will get the changes on their next update.


Pakistani Airlines website

  1. Airblue
  2. AirIndus
  3. Shaheen Air
  4. PIA

User story

A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures

  • What a user does or needs to do as part of his or her job function

User stories are used with agile software development methodologies as the basis for

  • Defining the functions a business system must provide, and to facilitate requirements management.
  • It captures the
    • ‘who’,
    • ‘what’ and
    • ‘why’

      Of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard.

User stories are written by or for the business user as that user’s primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.) though primarily it is the task of a product manager to ensure user stories are captured.

User stories are a quick way of handling customer requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.

A user story is an informal statement of the requirement as long as the correspondence of acceptance testing procedures is lacking. Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise whether the goals of the user story have been fulfilled. Some formalization finally happens when the developer accepts the user story and the acceptance procedure as a work specific order.

Creating user stories

When the time comes for creating user stories, one of the developers (or the product owner in Scrum) gets together with a customer representative. The customer has the responsibility for formulating the user stories. The developer may use a series of questions to get the customer going, such as asking about the desirability of some particular functionality, but must take care not to dominate the idea-creation process.

As the customer conceives the user stories, they are written down
on a note card (e.g. 3×5 inches or 8×13 cm) with a name and a description which the customer has formulated. If the developer and customer find a user story deficient in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory – often using the INVEST guidelines from the Scrum project-management framework. However, Extreme Programming (XP) emphasizes that user stories are not to be definite once they have been written down. Requirements tend to change during the development period, which the process handles by not carving them in stone.

A team at Connextra developed the traditional user-story template in 2001:[2]

“As a <role>, I want <goal/desire> so that <benefit>”

Mike Cohn, a well-known author on user stories, regards the “so that” clause as optional:[3]

“As a <role>, I want <goal/desire>”

Chris Matts suggested that “hunting the value” was the first step in successfully delivering software, and proposed this alternative as part of Feature Injection:[4]

“In order to <receive benefit> as a <role>, I want <goal/desire>”

Another template based on the Five Ws specifies:

“As <who> <when> <where>, I <what> because <why>.”

The <what> portion of the user story should use either “need” or “want” to differentiate between stories that must be fulfilled for proper software operation versus stories that improve the operation, but are not critical for correct behavior.


  • As a user,
    • I want to search for my customers by their first and last names.
  • As a non-administrative user,
    • I want to modify my own schedules but not the schedules of other users.
  • As a mobile application tester,
    • I want to test my test cases and report results to my management.
  • Starting Application
    • The application begins by bringing up the last document the user was working with.
  • As a user closing the application,
    • I want to be prompted to save if I have made any change in my data since the last save.
  • Closing Application
    • Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save!).


As a user closing the application, I want to be prompted to save anything that has changed since the last save, so that I can preserve useful work and discard erroneous work.

The consultant will enter expenses on an expense form.

The consultant will enter items on the form like expense type, description, amount, and any comments regarding the expense.

At any time the consultant can do any of the following options:

(1) When the consultant has finished entering the expense,

the consultant will “Submit”. If the expense is under fifty (<50),

the expense will go directly to the system for processes.

(2) In the event the consultant has not finished entering the

expense, the consultant may want to “Save for later”. The

entered data should then be displayed on a list (queue) for

the consultant with the status of “Incomplete”.

(3) In the event the consultant decides to clear the data and

close the form, the consultant will “Cancel and exit”. The

entered data will not be saved anywhere.


user stories define what has to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers.

When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written.

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to validate it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.


XP and other agile methodologies favor face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:

  • Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
  • Allowing developer and the client representative to discuss requirements throughout the project lifetime.
  • Needing very little maintenance.
  • Only being considered at the time of use.
  • Maintaining a close customer contact.
  • Allowing projects to be broken into small increments.
  • Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
  • Making it easier to estimate development effort.
  • Require close customer contact throughout the project so that the most valued parts of the software get implemented.

Story maps

A Story Map in Action

A story map is the graphical, two-dimensional product backlog. At the top of the map are big user stories, which can sometimes be considered “epics” as Mike Cohn describes them and other times correspond to “themes” or “activities“. These grouping units are created by orienting at the user’s workflow or “the order you’d explain the behavior of the system”. Vertically, below the epics, the actual story cards are allocated and ordered by priority. The first horizontal row is a “walking skeleton” and below that represents increasing sophistication.

In this way it becomes possible to describe even big systems without losing the big picture.


Some of the limitations of user stories in agile methodologies:

  • They can be difficult to scale to large projects.
  • They are regarded as conversation starters.

User stories and use cases

While both user stories and use cases serve the purpose to capture specific user requirements in terms of interactions between the user and the system, there are major differences between them.

User Stories

Use Cases

  • Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.
  • Must be accompanied by acceptance testing procedures (acceptance criteria) for clarification of behavior where stories appear ambiguous.
  • Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
  • May be delivered in a stand-alone document.

The INVEST mnemonic was created by Bill Wake as a reminder of the characteristics of a good quality user story.






The user story should be self-contained, in a way that there is no inherent dependency on another user story.



User stories, up until they are part of an iteration, can always be changed and rewritten.



A user story must deliver value to the end user.



You must always be able to estimate the size of a user story.


Sized appropriately or Small

User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.



The user story or its related description must provide the necessary information to make test development possible.



Tag Cloud


Get every new post delivered to your Inbox.

Join 2,840 other followers

%d bloggers like this: