Product Management

Importance of Screenshots in Requirement Document

2010-02-05T06:20:00.001+05:30

http://practicalanalyst.com/2010/02/03/give-em-pictures/

Fixed Price, Time & Material Project Models

2010-02-04T23:12:00.001+05:30

Fixed Price, Time & Material Project Models: http://weblogs.sqlteam.com/markc/archive/2004/01/03/683.aspx

Vignette's Content Management Tool

2010-01-22T14:23:00.002+05:30

Vignette's (now Open Text) Content Management Solution: http://www.vignette.com/dafiles/vcm8-demo/

This product looks impressive.

NEDSTAT, a Web Tracking Product

2010-01-22T14:05:00.002+05:30

NEDSTAT, a product from NEDSTAT that performs online user experience tracking (similar to Omniture's Site Catalyst 13): http://www.nedstat.com/web-analytics-segmentation?open&play_segmentation=1

SiteCatalyst 13: Site Tracker

2010-01-22T12:28:00.004+05:30

Omniture's (An Adobe company) 'SiteCatalyst 13' tool for tracking a website's user experience and generate reports out of it: http://www.omniture.com/en/products/online_analytics/sitecatalyst

A video demo of the product: http://www.omniture.com/en/product_tours/sitecatalyst13?fc=true&v_id=522482

Six Sigma

2010-01-21T17:30:00.003+05:30

What is Six Sigma? http://en.wikipedia.org/wiki/Six_Sigma

Swimlane Diagrams or Cross-Functional Diagrams

2010-01-21T16:20:00.003+05:30

Swimlane Diagrams or Cross-Functional Diagrams are described in the below link:
http://en.wikipedia.org/wiki/Swim_lane

How to draw? Components of Swimlane: https://www.niatx.net/PDF/PIToolbox/swimlane.pdf

Joint Application Development (JAD) Session

2010-01-21T15:54:00.002+05:30

What is Joint Application Development (JAD)? http://www.businessanalystfaq.com/what-is-jad-session.htm

How to setup a JAD session? http://www.ehow.com/how_2068255_set-up-jad-session.html

SDLC Models

2010-01-21T11:08:00.002+05:30

Software Development LifeCycle (SDLC) models:

Waterfall Model
V-Model
Prototyping Model
RAD Model - Rapid Application Development
Incremental SDLC Model
Spiral Model
Agile Model

- Extreme Programming (XP)
- Feature Driven Design (FDD)
- Dynamic Systems Development Method (DSDM)

Explanation on the above shall be found in the below three links:
http://www.onestoptesting.com/sdlc-models/
http://www.scribd.com/doc/5195326/PPT-on-SDLC-Models
http://en.wikipedia.org/wiki/Agile_software_development

UML, BPM Certifications

2010-01-21T10:20:00.002+05:30

Object Management Group's (OMG) BPM Certification in Business and Technical side: http://www.omg.org/oceb/coveragemap-links.htm

OMG's UML Certification: http://www.omg.org/uml-certification/

IBM's Business Process Analyst Certification (BPM):
http://www-03.ibm.com/certify/tests/ovr372.shtml

Why-to-use: UML, Use Case

2010-01-21T10:08:00.000+05:30

Why to use UML? http://www.cragsystems.co.uk/why_use_uml.htm

Why to use Use Cases? http://www.cragsystems.co.uk/why_use_use_cases.htm

BPM and SOA (Service Oriented Architecture)

2010-01-19T09:44:00.002+05:30

What is BPM and SOA: http://www.microsoft.com/soa/about/whatis.aspx

A good set of BPM and SOA FAQs can be found here: http://www.microsoft.com/soa/about/faq.aspx#soafaq The FAQs are very useful.

10 real life examples of SOA implementation: http://blogs.zdnet.com/service-oriented/?p=508&tag=rbxccnbzd1

History of BPM

2010-01-18T14:17:00.003+05:30

Very good writing about the history of BPM can be found in this link: http://www.ebizq.net/blogs/column2/bpmhistory/

This link has 8 parts in it, ranging from Start to Current State. The author has explained about Workflow, EAI, integration of these two.

A strongly recommended reading material.

Bizagi - BPM Tool

2010-01-15T14:47:00.004+05:30

Downloaded the trial version of Bizagi; also downloaded a PDF detailing an example ("Vacation Request Workflow"). The tool in general has a good UI, but couldn't understand the functionalities of it. The content in the PDF document is out-dated with respect to the latest Bizagi software. The tool claims that it can create a working model of the process model. After struggling for 1 hour in the tool, I closed it as I couldn't proceed any further because of the lack of usability / documentation.

Business Process Management (BPM): Introduction

2010-01-13T14:55:00.003+05:30

A very good starting point to understand Business Process Management (BPM) - www.bpmbasics.com.

Read in this order for better clarity: Introduction section, BPMN Notations, Examples (going through 2 or 3 is enough), Resources (webinars are good).

For BPMN Notations, you may want to refer http://www.bpmn.org, esp the BPMN Notation Graphics section at the bottom of the page.

BA role in ThoughtWorks

2009-11-20T04:27:00.004+05:30

A YouTube video on the role of BA in "ThoughtWorks":http://www.youtube.com/watch?v=cbNmVUbdKRo&feature=player_embedded

This video primarily focuses on role of "Iteration Manager". Would be glad if they could video it out focusing a BA role.

The environment looks very nice, collaborative and inspiring. Am sure this kind of environment will kindle innovation and creativity.

"FireShot" For Screen Capture

2009-07-16T21:30:00.002+05:30

Fireshot is a godsend add-on (for BAs) for FireFox. With FireShot, the page displayed in the screen can be easily captured, edited (add comment, crop the page, highlight some portion of page). Then this edited image shall be used to explain requirements. You need not open MS Paint anymore.

Accepting requirements gap

2009-07-09T08:34:00.001+05:30

While explaining requirements to teammates, if a gap is found, humbly accept it without losing focus / mood / temper. People will point out the gap infront of every team member in the requirements walkthrough meeting. Take it in a positive spirit. Note down the gap and incorporate in the document. Its ok, BAs are also humans and they tend to do mistakes.

Include screenshots wherever possible

2009-07-09T08:32:00.000+05:30

While writing requirements, try to include a screenshot (if you are documenting an existing functionality) of the functionalities. If there are no screenshots and only text explains a requirement, chances are that the functionality might be broken in the current project and you will have a tough time proving that the current project broke it. Teammates might just point that the BA have documented wrongly. So, a screenshot of whatever you write always helps.

Reciprocate (like a spring) on clarifications

2009-06-22T16:43:00.003+05:30

When a clarification is raised on a requirement from the team and you await clarification from the customer end, make sure the clarification is obtained from the concerned person ON-TIME. If the clarification is not cleared even after 2 days, make sure you follow up with the customer daily to get it clarified.

Bottom line: Developers, testers should always have a clear, unambiguous and unquestionable requirement in mind ALWAYS.

Explain every term in FDD in the FDD itself

2009-06-22T16:38:00.004+05:30

Every term you use in the FDD, make sure that the term is explained to its maximum detail possible in the FDD itself.
Example: "The user of this application will be Billing Consultant". The FDD should talk details about who is a Billing Consultant, what is the scope of the user, what all role privileges the user has.

If a term is not explained in the FDD, then it will be logged as a requirement defect. Then, again you will have to update the FDD with the explanation for the term.

Prevention is better any day.

P.S: FDD - Functional Design Document.

BA role boundary

2009-06-16T23:19:00.003+05:30

A golden rule: Mind your work :) to be specific, mind your role.

Even if you posses knowledge on the development language of the project (Java, .Net, C++ etc.,) or you have the brain of a QA person or you have some of the PM's capabilities, maintain limits on the tasks that do not fall under the "BA's Bucket". If you are pitching in their (DEV, QA, PM, Module Lead etc) task, then it might impose a bad impression on you. Though some people will welcome the help that you offer for them, not all will take it in the right spirit. To play the game safe, better mind your role :)

"Lighthouse" Application

2009-06-16T22:09:00.004+05:30

Lighthouse - an application for Requirements Management, Project Management, Create and maintain Test Cases, Test Scenarios, Uploading DEV + QA docs, logging defects, defect management, maintaining timesheets. You can integrate all these components, meaning - you can map a requirement to a particular test scenario etc.

I explored the requirements management component and found it a little difficult to use. Not impressed with the user interface and usability.

You may try the Lighhouse application HERE.

Screenshots: Attention to detail

2009-06-15T22:08:00.004+05:30

While including screenshots in the requirement document, make sure that all its related screenshots are in sync in terms of data, user interface fields.

Screen A reporting a value of 10 USD. Screen B reporting a value 20 USD. In Screen C, if the requirement is to sum the values of Screen A and B, at this point if the value is displayed as 40 USD in Screen C, then its a clear problem. Agreed that its just a sample screenshot to let the DEV and QA members know about the UI fields properties. But, at a later point of time in the project, when somebody looks at Screen C alone without reading the documentation of it, they will get confused on the calculation of Screen C value. Whether Screen C calculation is wrong / value present in Screen A is wrong / B is wrong? Confusions. If the computation logic is complex (as in Finance / Invoicing etc), then its a much bigger problem.

Golden rule: Screenshots should depict correct values in it, all its related screenshot should also be in synch with it.

Knowledge Transfer (KT) at one shot in the start

2009-05-31T17:42:00.004+05:30

Lets assume there are 5 iterations in your project. If the project team (DEV + QA) asks for knowledge transfer (KT) of every iteration at different phase of the project, do not agree for it at any cost. Meaning - if the KT of the iteration's usecases has to start only when the iteration is about to be developed, then its a huge risk that you are taking voluntarily.

Iteration 1: Development start date is June 1
Iteration 2: Development start date is July 1
Iteration 3: Development start date is August 1
Iteration 4: Development start date is September 1
Iteration 5: Development start date is October 1

Why?

If you explain the Iteration 1 usecases on June 1 and Iteration 2 usecases on July 1, then many problems would arise. Both the devvelopement and quality assurance team would not have a big picture of the project. They can only see few meters of the road, they cannot see the entire road ahead of them. This might lead to gap in understanding requirements. Rewrite of codes once the other Iteration usecases are discovered during KT. Possible change to database design altogether. Rewrite of test cases, test scenarios for the QA team.

You would also be put in a situation to give multiple rounds of KT. Its not that both the development and QA task of Iteration 1 will end on June 1. What if QA tasks (writing test cases, scenarios) are completed by June 20 itself? Then for the next 10 days, QA team would have to sit idle. In order to avoid this, you will have to do a seperate round of Iteration 2 KT for QA team and another round (repeat work) of Iteration 2 KT for development team on July 1.

To avoid all these, its really better to give KT of the all the Iterations at the start of the project itself.

NO database details in Functional Requirement Document

2009-05-31T16:56:00.005+05:30

While writing requirement document, do not even include the database designs - description on database tables, columns etc. Even if you are an expert in DB design, do not describe DB details in a functional requirement document. As BAs, we aren't supposed to include technical details in requirement docs.

Problems with DB design details in functional requirements doc:

You are a BA. Not a DBA. What's the guarantee that what you had written is correct?
If the details are wrong, then while implementing the functionality, development team will figure it out and the change in database design will be called as a Change Request. This is unwanted cost for the customer, extra work for the BA to change the requirement document, confusion for the development team as well.
Lets say a Usecase ABC is using a column "Test_Column_Name" in a table called "Test_Table_Name". In the later course of the project, if this usecase has to be descoped for whatever reason it is, then there are two problems.

- You will have to remove the dependent columns (of that removed usecase) from the requirement document. More importantly, what you are doing should be correct.
- If you forget to remove the dependent columns (of that removed usecase), then the development team will create this column in database. At later point of time in project, this column need to be removed from the table. Unwanted chaos.

Considering all this, the golden rule is: Never bring in technical details into functional requirements document. Technical team is there to figure out technical details.

The Business Analyst Role

2009-05-29T17:57:00.001+05:30

Many and Many had asked me this question "What is the role of Business Analyst in IT"?

Invariably, I had explained in detail to all the people who asked. Below is the explanation that I give for this question:

Business Analyst (BA) is a liaison between the project team and the client interms of requirements of the project. Usually, the project team will be an offshore team with respect to the client's location. Once the project is confirmed from the client side, BAs are expected to travel to the client's place to gather requirements about the project. BA will have to understand what exactly the customer needs. In some cases, the customer might not be able to express the requirements clearly, in those situations it is upto the BA to ask the appropriate question to get the requirement from client. BA need to schedule meetings with all the stakeholders of the project and understand their needs. There are many ways to do this. It could be a one-to-one meeting or a group meeting or email discussion or telephonic etcetera. Requirement gathering usually takes 1-2 months (depending on the size of the project). BA should complete the requirement gathering within this time span. As and when the BA gets the requirement, they will have to be documented, again, there are lot of ways to do it. When the BA feels confident on the requirements gathered, those requirements should be converted into usecases. Then, order / arrange the usecases into groups / sections and that forms the requirement document. Usually its a MS Word / PDF document. Also, the requirements traceability matrix document should be prepared. This document would contain all the usecases and their dependencies, their priorities. Then, the Non-Functional Requirements (NFR) document has to be prepared. These documents should be explained to all the stakeholders of the project and their agreement has to be documented. This process is called "Sign-Off". I would call this as "Phase 1" of requirements gathering.

Once the document is signed-off, BAs will travel back offshore. BA will have to schedule meetings with the entire offshore team for knowledge transfer (KT). During the KT process, the entire requirement document and other documents will be walkedthrough by the BA. During the course of KT / implementation phase, if there are any clarification in requirements that leads to Change Request (CR), then it has to be escalated to PM. PM would then ensure that the CR process if followed to implement the CR. During the implementation phase, BA has to clarify any requirement related questions from the project team. Any clarification that needs update to the requirement document has to be updated. This is called Requirements Management. Multiple periodic demo of the project (an application) will have to conducted by the BA to the customers. This would give confidence to clients - 'what is developed is what is asked for'. BAs also need to perform periodical testing of the application that is being developed. This would ensure that the correct product is built and not building a product that is correct. If any new member joins the project during the implementation phase, BAs are responsible to bring the person upto speed interms of requirements. Once all the functionalities are developed and QA'ed (Quality Assured) then the project will have to deployed live. After the deployment, BAs should test the product for its functional working.

While working on a project,

BAs are also expected to collect requirements for another project. BAs should be multi-tasking.
BAs are expected to do RFP (Request For Proposal), RFI (Request For Information)
BAs should always and constantly update their knowledge on the domain of their work (Example: BFSI, Travel & Transport, Insurance etc.,)

There ends the BA role.

Disclaimer

2009-05-25T23:55:00.002+05:30

The author of this blog will NOT write about -

Any company on earth
The project he had worked / is working for
Past and current clients

The author of this blog will write about -

IT Business Analyst (IT BA) - Role description. Everything below is with respect to IT.
BA Tips & Tricks
Articles on BA role
Tools for BAs
BA common mistakes
BA - Dos and Donts

Any information abstracted from Internet belongs to the author / owner of that content.