software requirement

Five ‘must-have’ skills to be a Business Analyst

As stated in my previous post, a Business Analyst is a quite powerful role that establishes the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer. Let us see what are the ‘must-have’ skills without which a business analyst can not survive? And why are those skills so important to be a business analyst? Without any relevance to the order in which they are mentioned (as all are equally important) these skills are:

5. Business Knowledge: A good amount of experience/ exposure/ knowledge of customer business are very important for a business analyst

4. Listen and Understand: A business analyst has to be a good listener and with a sharp understanding power without which all the discussions with customer will be fruitless.

3. Technical Knowledge: There will be quite a few technical discussions at customer site. The BA has to be quite conversant with the technologies and methodologies present at his organization.

2. Communication: A business analyst has to be a strong communicator. During the customer meetings, if he does not communicate well about his organization’s capabilities to build up the trust and confidence, probably customer may not gel well with his ideas.

1. Writing skills: Very important skill required for documentation and for conveying the right messages across the board.

Various roles of a Business Analyst

Business Analyst is a quite powerful role forming the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer.

For a software company having various new development projects a business analyst has to understand the existing business processes, methodology, rules etc. of the customer, document it (which itself is a specialized task) and hand it over to development team to embed the customer requirements into the software to be built.

For a software (or IT) sales company a business analyst has to sit behind the sales/ business development teams – understanding their current process of acquiring new business or sustaining current business and bring out a better approach, methodology, process to enhance business in terms of new business and holding current business.

For a manufacturing company a business analyst has to understand the process, re-engineer it to enhance the production, product yield, thereby increasing customer satisfaction and reducing defects or rejections.

A business analyst ‘s various caps thus include – business process analyst, business strategy analyst, business methodology analyst thereby becoming a backbone to business process managers, sales teams, management, development teams , product teams, quality teams etc.

Dear software developer – what is your mileage?

I have two sets of developers. Both bunches contain quite considerable number of developers. Let us call it first set of developers and second set of developers. Both sets have their own unique way of functioning and performing.

First set of developers work randomly with no documentation, no fixed plan in place. The requirements come invariably from different directions and as soon as a new requirement comes, the developer changes the priority of his tasks based on the influence of the requirement generator. In this manner after sometime the developer loses his track of what elements he has addressed or fixed and which are pending as there is no systematic way of recording requirements and their completion track.

Second set of developers works absolutely in different manner. They record all the requirements in one place, prioritize them, maintain software version control, mark each requirement as completed only after their satisfaction and testing and reassess their requirements at each day end. This way they never lose control and are absolutely clear on what is balance and estimated time required.

Surprisingly first set of developers spend more time at work place but product less result as compared to second set of developers.

Let us compare this with two similar cars with their fuel tank full. First car is driven randomly on road for whole day without any specific purpose and exhausts its fuel at the end of the day. Second car driver is sensible in planning his route before starting his journey, reaching back early in the evening, finishing more tasks with still some considerable fuel left in his tank.

Different Software Applications have different set of Risks involved

Any activity is never without risk involved in it. Risk could be classified in different categories like - low, medium or high depending on its impact, software’s requirements and purpose, software usage, and software user volume. Accordingly the risks are identified or rather perceived. Their impact is measured or assessed, and based in the category in which it falls into – its countermeasures are designed or defined. The right identification of risk is as important as its classification or category.

A classic example could be a bank application being used by all its customers for their account maintenance, for transactions and for various other purposes. The risks involved in this sort of application could be: availability of application to all its users all the time, the speed of the application, the security of transactions, the ease and comfort of usage, the user account vulnerability of hacking and so on.

Some applications required all time availability whereas other demand high performance and high availability at peak time. Say, for example there is a website of a university where the peak usage is only at the time of admission or enrollment, at the time of fee payments, and at the time of release of results. At these times the volume of this site usage will be extremely high. So not only it demands availability of application at critical or peak times but also to be ensured is that it does not crash down due to high volume of use.

So it is very important to identify the right risks, to understand the right impact size, and to derive at a right countermeasure.

Top 5 Quality killers in a software product

In software development project what matters most is the timely accurate delivery that gives the benefit of defect free product, customer satisfaction, profits, market edge, growth, motivation across the organization etc. All this is not easy to achieve having so many enemies in and outside the organizations that mars the development progress or a sub-standard product. These negative factors or enemies lead to a low in quality product that faces a tough time at customer end resulting in rejection. To name top 5 quality killers in a software product, I would list them as below:
5. Requirements: customer requirements or product requirements is the foundation of software. Any sort of compromise in this would lead definitely to a disastrous product.

4. Management: Intensity of management’s involvement in the product development throughout spells out the success or failure of a product.

3. Documentation: Development plays an important role during a product lifecycle and so does the documentation.

2. Customer Involvement: The involvement of key users at all levels of development and implementation is quite crucial.

1. Testing: ‘When’ to involve the ‘testing’ team defines the earlier successful completion of a project.

How to Create, Build and Maintain Harmony between tester and developer

‘Create’ means the first time effort to generate a harmony between a tester and a developer working on the same project. ‘Build’ is the next stage after create to harmonize the professional relationship between a tester and developer. This step will bring the strength in the relationship. ‘Maintain’ is not only the sustenance of this healthy relationship which can be termed as ‘sweet’ harmony, but also calls for an effort from both ends to ‘keep on improving’ this bonding. To create, build and maintain an everlasting harmony between the testers and developers, here are some tips:
1. Share: Sharing is a two way process. Both the sides need to share equally, transparently and openly. The development team needs to share the customer requirements, business rules, relevant documents, design plan, coding, system built. On the other hand the tester needs to share his observations on all these, and the results of his testing. Share problems, thoughts and success together.
2. Raise an Alarm: Tester and developer require raising an alarm in case of any shortfall in above sharing required from both ends. Developer also needs to raise an alarm in case of inadequate testing or if testing is getting delayed due to any reason.
3. Act Jointly: Tester should sit with the developers while they are on job i.e. designing system, and similarly developer whose product is being tested preferably should sit with the tester while he is testing the product. This support will not only strengthen the process and product but will make it more secured.
4. Avoid Protectionism: On the work front, be it of a developer or a tester, it is important to prevent the spread of protectionism and to promote transparency or openness across the organization. If this is not handled properly, it may lead to depression and incoherence across.
5. Accept Framework: Accept each other’s work framework and respect it by heart.
6. Resolve crisis: In case of any crisis on any front leading to adverse effect on the project, take all necessary measures jointly, timely in a coordinated manner. Be more than willing to act in this regard.
7. Tester is a bridge: Tester is a bridge between developer and customer for the purpose of smooth and defect free delivery of product to the customer.
8. Be a great contributor: To achieve great success, be a great contributor in your respective fronts.
9. Encourage: Encourage each other.
10. Remember: Always remember that you have joined hands to achieve a common goal. A good harmony always brings in the ‘success’

New Release for testing – a tester’s paradigm

A new software release for testing could be a new product or major changes in the existing software. In either case the bugs report should have a new version number for control purposes. Although in case of a new release of existing software, the existing bugs can be referred to but that does not mean to check only for those bugs.

Anyhow before the tester starts testing of this new release (or for that sake of any new release!), (s)he has to make sure of three certain activities:
1. Clinical review of the testing requirements
2. Known bugs (in case it is a chain release) fixed
3. Scope – customer requirements, software requirement and business rules

And above all now tester’s task is to ensure that the software (re)built is completely aligned to the above three.

SDLC-I: Software requirements

Software requirements are the requirements that are given to the developer based on which they build new software. Software requirements could be functional or technical in nature. Broadly software requirements can be divided in two parts as – business process and business rules. Software requirements lifecycle can be defined in following steps:
1. Initial discussions – in this phase the top officials of the two parties (customer and vendor) discuss broadly the business requirements that are required to be built in the software.
2. Detailed discussions – this phase comprises of a team from vendor side that goes to meet the respective process owners of customer to understand the details of each process and the rules to build in.
3. Documentation – the requirements (process and rules) in the above process need to be documented in a clear manner because this is going to be the basis of software.
4. Forms and Reports – any forms and reports that are in business practice and have to be built in the software will have to be collected.
5. Sign Off – Never forget to get the complete document signed off by customer key users and top management

10 Must-do for Vendor to have clear Software requirements in first go!

This is in continuation of my previous blog where I listed the 10 most important must-dos for customer to have clear software requirements in first go. Ten most important must-dos for vendor to have clear software requirements according to me would be:
Vendor End:

Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if! Any!!).

10 Must-do for Customer to ensure clear Software requirements in first go!

Having clear software requirements is very important as it is going to be the foundation of the software to-be-built. Having clear software requirements in first go is equally important especially in case of overseas client. Few things are very well known to all:

Keeping all this in mind, the 10 must-do to have clear software requirements in first go, which I am listing below. There could be many more (which I would like to be added in the comments section), but these come to my mind as most important:
Customer End:

Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if!). A similar set of guidelines for the vendor end, I would be posting in my next blog.