The Requirements Document

The requirements document can never be perfect unfortunately. Most requirement documents are outdated before someone actually reads it but it is still a very valuable tool for documenting requirements in a lot of organisations. It is also often pivotal to the project to both go to business case or progress into an analysis and design phase, depending on their company methodology. This page will give you tips for how to manage your requirements document in terms of feedback, approvals.

Who should Review & Approve the Requirements Document?

A good place to start when determining the readers (reviewers and approvers) of your project requirement document will be your stakeholder list. Focus here on both the requirements document specific stakeholders but also some other high priority stakeholders for the project. Although it is important to involve the correct people in providing feedback and approvals, you should really try and keep this to a minimum number of people.

Sometimes you need a few senior stakeholders' sign off too and they may not have been very involved in the process of gathering and reviewing requirements during the documentation phase. You deal with this situation by offering to provide them with a summary walkthrough of the document. You can present this summary in an executive style presentation pack which talks their language. When you do the actual walk through session with them always also have to complete requirement document handy. Ask whether they have any questions or concerns. If they can't commit to approval as an outcome of that walk through, ask them under which conditions would they be ready to provide approval.

How do you gather feedback from reviewers?

A quick way is to do a walk through session. Send your requirements document out to all reviewers a week before (if you have luxury of time) and schedule a couple of walk through sessions. Ideally capture people's feedback there and then and update it online there and then! This is ideal. If you need to send them an electronic copy, try and get them to use a requirements feedback form instead of making direct updates to your requirements document. Make it clear when you expect to have all feedback in and if your stakeholders are tardy in responding (which they often are!) give them a call and ask whether you could schedule time to walk them through or answer any questions.

Getting that Approval!

First talk to your project manager and determine which approvals are really critical for the project to be able to progress. They normally have a sub set of key people that really need to approve from a Steering Committee perspective. There are sometimes people on the approvals list that is not that crucial to get approvals from or you could accept delegations. Once you know who the key people are, rope your project manager in to help you chase approvals with more senior people. I am of the strong belief that our requirement document is a project deliverable and not technical our responsibility to chase! I am sure some PM's will disagree...you decide.

Business Need

As first step, we identify and engage with the key stakeholders. Have chat, a formal stakeholder interview or even a problem definition workshop, but it is essential to start the hunt for more information on ‘the business need’. Find the people or person who raised this need, talk to them first. The key stakeholders are those groups or individuals in the organisation that is affected by the current business problem and who will be affected by us introducing a solution. We will use various requirements gathering techniques and review many types of materials in a quest to understand their need or problem. Example stakeholders often include: department heads, business area managers, operation staff and off course your own project team members who may have information too!

Typical other sources of information of the business need or problem to find during this activity can include business cases, process documents, existing systems and artifacts such as invoices, application forms and so on. There are many different ways that we go about trying to understand what the business need is. A lot of collateral (more specifically referring to the Soft System Methodology as an example) will refer to this activity as the process of gathering information to understand the “unstructured” version of the business problem we are aiming to fix.

Translate the business need into an objective, clear and specific language.

Once we have gained a grasp on what the business need is, we start to translate and interpret that need into a more structured problem, need or description of our scope. Very importantly at this stage we document the business need into a language (business requirements, software requirements or functional requirements) which can be understood by the business. We don’t dive into any technical modelling or ‘analysis speak’ but where appropriate we will use techniques to illustrate the problem.

By now you would have used a decision making model to choose between methodologies and decided which one will fit best for your business requirements management on the project.

This key step of clarifying and drafting the business need can include diagrams such as use case diagrams, activity flows or process models to express the problem. These are great tools to use to demonstrate an understanding of a business problem’s current state and assist you in ensuring there is clarity around what the business need it that is being addressed. This step is iterative and involves a lot of discussion, rewriting, redrawing and finalizing of what it is we are trying to solve. A handy tip here is for you to always get to the bottom of WHY is something a problem.

Once we clarified, expressed and agreed what the current business need is, we start the process of brainstorming ideas of how we can address this need (really start to gather business requirements in earnest). What is the stakeholder’s nirvana, what do they believe is the solution that will address the problem. Again, this process involves you engaging with all the stakeholders and getting people’s views in the most appropriate way. This can include more business requirement workshops, stakeholder interviews or even doing market research for relevant trends and products.

Important to note: You will find that the business stakeholders will start with the solution and often start providing software requirements way before stating and understanding the root of the problem of business need. It is your job to get to the problem or business need first!

Manage change of business needs in our project.

Another very important part of this role on any project is to manage the change of requirements right from the very start of any business or technology project. It doesn’t matter whether you are on a mostly unstructured waterfall based project, or whether you are on a closely managed Agile project the one thing that you will be managing is change. Change to business problem, change to requirements for a solution and change just because. All projects consist of a myriad of people and where there are people, there is constant change. It is well worth your while to plan for how you will manage change to your business scope, your requirements and once you start implementing a solution, and how this will be managed. If you don’t manage the change factor on your project, you may be swallowed whole.

Build solid relationships with all stakeholders.

Leaving this crucial point to last is definitely not because it is least important. It is because it is most important! If you don’t have good relationships with the business stakeholders, your project team stakeholders and the supporting technical team stakeholders you will fail. You will not be able to do any of the above three important tasks effectively and business requirements efforts will not be as good if you neglect building strong relationships with everyone involved. This is key – know who all your stakeholders are, engage with them often, build strong rapport with primary stakeholders and keep communicating. You will build trust this way and it will make your work easy, rewarding and best of all you will deliver high quality output.

Requirements Traceability

Why would you want to trace requirements?

Requirements traceability have a few reasons why it is necessary to be completed during the System Development Life Cycle regardless of what methodology you follow.

Keeping track to of progress of requirements in the  Software Development Life Cycle.

As a Business Analyst you are responsible for ensuring requirements are being delivered as requested, it is important to use a requirements management tool which will link your individual requirement to agreed scope items and the subsequent Software Development Life Cycle phases. This way you will always know whether a requirement is on track to be successfully implemented.

When you start having a lot of requirements, it becomes more difficult to manage and track progress of each requirement, and this is when linking a requirement to the other stages in the SDLC becomes really important. The business stakeholders love coming back to the team and they want to know what happened to ìtheirî requirement they wanted.

The other reason for requirement traceability is to manage and trace the changes made to requirements. For example, you will find that as the  Software Development Life Cycle rogresses there will be some requirements that change. This could be due to many reasons but often it is the business stakeholders changing their minds and sometimes it is a project decision based on more technical reasons, the bottom line is, you need to keep track of what changes are made to a requirement. You do this via your traceability management tool or a simple requirement management matrix.

A few factors to consider Requirements Traceability approach:

Which tool will you use for Traceability?

Sometimes people simply use a MS Excel Traceability Matrix Template to capture the tracking information. More sophisticated Requirements Management Tools, such as Calibre RM, could be used to manage this too.

Who will be responsible to manage the Requirements Traceability?

It needs a champion and central point. In some projects, you may be long gone (i.e. reassigned to a different project) by the time requirements are being tested and therefore you are not there to update the traceability matrix.You need to consider who can you hand the requirements traceability over too if you are not around for full  Software Development Life Cycle.

When do you start the Traceability process?

Depending on your method of capturing the traceability information, this could vary slightly. A general accepted practice is for you to establish your traceability using the signed off business requirements. Any changes post business requirement's sign off will be managed via the traceability (and Change Request) process.

Important Q & As

What is the importance of a flow chart?

A flow chart is a tool that provides a graphical representation of a process. This chart will make a system easy to understand for everyone that is involved with the project that is underway.

What is a use case model?

A use case model is a tool that is used to describe the business environment. The goal of the tool is to show the actions and events that take place during a given process that is performed by an actor.

What is UML modeling?

UML stands for Unified Modeling Language. It is the standard in the industry for visualizing, documenting and constructing various components of a system.

What is an activity diagram and why is it significant?

The purpose of an activity diagram is to provide an outline of work flow in the business, including the action and activities that are completed. 

Business Analyst in SharePoint

When i was browsing i found these very important articles on SharePoint BA role.It was written by Michal Pisarek and the article was published in https://www.nothingbutsharepoint.com/sites/eusp/pages/what-makes-a-good-sharepoint-analyst.aspx


It is mentioned that with SharePoint being such a new technology, and unique in the skill sets required, the role of SharePoint Analyst has become a role that seems to encompass many differing skill sets. But what exactly is a SharePoint Analyst and does the role of the SharePoint Analyst differ from a more traditional Business Analyst?

The SharePoint Analyst role is a unique combination of platform knowledge, business acumen and interpersonal skills. Someone that is comfortable in technical details but equally comfortable training end users or explaining tangible business returns to executives.

What makes a SharePoint Analyst different to a 'traditional' BA?

When working with SharePoint there is a fine line between the 'prescriptive' and 'descriptive' approach. Whilst a traditional Business Analyst will ask a client what their needs are, a SharePoint Analyst needs to balance this with the capabilities that the platform offers and how it can be leveraged to most effectively satisfy business objectives. This does not imply that user requirements are disregarded, or that platform capabilities will be put ahead of business needs. However SharePoint offers a multitude of business solutions, with varying degrees of complexity on many levels such as deployment, architecture, development and customization which a SharePoint Analyst needs to have an appreciation.

A good SharePoint Analyst will always seek to gain maximum business value from the various components that SharePoint offers. Remember that SharePoint can be viewed as both a product and platform, the most successful SharePoint Analysts will balance time, budget and scope to determine the most successful solution approach.

Platform knowledge

For better or for worse a good SharePoint Analyst needs to have some knowledge of the multitude of capabilities that SharePoint offers. Some appreciation of out of the box configuration, infrastructure knowledge and development experience.

This does not imply that the SharePoint Analyst is a master of all of these skills, or can even perform them. But the SharePoint Analyst needs to know the 'what' of the platform, not as much the 'how'

The 'what' refers to what the platform can do and what it can't, and where the line is between configuration, customization and development. The 'how' is the deep vertical technical knowledge that is the realm of so many brilliant people in the community.

Now the reason that the SharePoint Analyst needs this knowledge is twofold. Firstly SharePoint is a platform so in theory it can be molded to do anything you like, but this doesn’t mean that it should. Secondly being able to steer conversations around high value, low risk alternatives to heavy customization can provide incredible value. I am sure that the EndUserSharePoint audience appreciates this more than most. If you can help your client understand that a small tweak in a business process can reduce the complexity of the solution by an order of magnitude you will have both happy users and a high return on investment for your client.

But also there are times where customizations will be needed. A SharePoint Analyst needs platform knowledge in order to manage user expectations of the complexity this might entail. With so many capabilities SharePoint is seen as a solution to everything, the SharePoint Analyst knows this not to be the case and can help their organization understand where the platform can be most effectively applied.

Steering the Ship

SharePoint is unique for many organizations because it is one of the few products that can have an impact in so many areas of an organization. A good SharePoint Analyst will be the captain steering the ship through the murky waters that can quickly become most well intentioned SharePoint project, program or implementation.

But as captain you have to make sure that you know where you are going, then determine how you will get there. This is where the SharePoint Analysts business acumen comes into play. Contrary to what most people think SharePoint is first and foremost a business tool and the SharePoint Analyst has to be very clear about the business problem that is trying to be solved.

Secondly a captain needs to make hard decision and be honest. You will have to say no more often than you think to make sure that the ship stays its course. You have to ensure that business problems are being solved in the most effective way and that SharePoint doesn’t become an exercise of technical prowess. The SharePoint ship can be quickly pulled in many directions all at once, make sure that the choppy seas of unclear business problems and intangible business returns does not run the ship aground.

Finally with a clear understanding of where the ship is heading to it is up to the SharePoint Analyst to make sure not only that it arrives there, but it’s does so in the best condition with minimal issues. Educating clients on seemingly unrelated issues around SharePoint such as governance, usability, adoption, training and others issues calls into play the SharePoint Analysts interpersonal and business skills. In many implementations the SharePoint Analyst finds that the technical challenges are far easier to resolve than the change management needed to ensure a successful solution.

SharePoint Analyst Attributes

    Be passionate about what you do: SharePoint can bring joy, frustration, pain and sometimes humor. If you are not passionate about the business issues you are trying to solve, and the platform you are using to solve these issue with, you may quickly find yourself descending into madness.
    Show compassion: We understand SharePoint but for many end users and business leaders this is a complex and intimidating product. Be compassionate, understand that people will need extra time to understand and possibly adopt the platform.
    Have restraint: Don’t make your SharePoint solution an exercise in technical brilliance whilst providing little value to end users. Use only those features that will solve business issues and improve outcomes, don’t show every feature of the platform at once. Start slow, stay the course and provide value.
    Humor:  Laugh when you don’t know the answer, laugh when a CU breaks a service application, laugh when you realize that something that should be easy needs heavy customization. Trust me it’s better than crying.
    Learn, Explore and Contribute: A SharePoint Analyst doesn’t know it all, but that doesn’t mean that you should stop learning. So much knowledge is available with a mouse click, the results of thousands of hours of unpaid community contributions. Learn from it, explore SharePoint for yourself and try to contribute. You don’t have to write a blog, you don’t have to answer forums but even a tweet to an author, or a comment on a blog can bring someone a smile.

SUCCESS

If I ask you how much do you want to be successful?


Do not dream to be a successful person.Never be a dreamer.I should tell you always feel the necessity to be a successful person.Dreams would take you no where though the want to be successful or the necessity could do miracles.

Once there was an old man getting down from a very sophisticated vehicle, a small boy watching him went to the man and asked  so how did you achieve  all this success in life?This the old man said "Okay boy if you want to know how to achieve success , meet me tomorrow in beach." As discussed the boy meet the old man in the beach and then the old man says "If you want to learn the secret of success you much come to the ea with me." , nodding the head the small bog agrees to the old man and they are now in the middle of the sea and again the old man turns to the boy and ask "Boy do you still want to be achieve success" , then the buy turns to the old man and say "YES, but i don't want to die before i achieve it"The old man then pulls the boy's head and since the power of the grip of the old man , he could not  come up from the water.Releasing the boy the old man said "WANT SUCCESS AS YOU WANTED TO BREATH INSIDE WATER" .

So success must be the  necessity and not the dream.Success comes with the ability of facing risks.If you can take up challenges face them as a real human then you contains an important quality which you must have when climbing the ladder of success.So if you are in the boat now get in to the water and try to swim.Have faith in your self.

It requires your full time dedication and accurate decision making skill.If you really want to achieve success you must take accurate decisions on each and every small thing you do and get your self 100% committed to it. society do contribute  towards once success.So being a social animal can help a lot on what you want to achieve.Remember "PEOPLE LIKE PEOPLE WHO ARE LIKE THEM". So networking is another very much important quality in the ladder of success.

Personality matters a lot for success.People like to buy from a successful seller and not from an unsuccessful seller.So the way you talk or dress or look or behave or everything matters when dealing with professionals and even in the personal life.

 Be innovative.Think and do rather doing for the sake of it.Always take the opportunities and try to add value to the profile on everything you do.Build the recognition within your friends and industry you work.


Life is not easy going friends.Take and do in the best way.Hard work always pay off.


“Genius is nothing more nor less than doing well what anyone can do badly.”

"Leadership" is made or born? If they are made,what are the steps to develop them?

​It is the decade of leadership.
I would rather say that leaders are both made and born.
Let us discuss more on it.If leaders are born, some people get the qualities of leadership from their birth it self.They have it in their blood.They have a good personality.They are innovative.They have a very powerful voice which matched to their personality.They have the ability to lead the people around them.They are always self guided and and always able to set examples for the people around them.Those people create values to the society as well as to the whole human creatures.This is not an easy task.Thus some lucky set of people bring them from their birth.They do not need a title thus are leaders by birth even with out the so called title "Leader".
There are another set of people who not bring leadership qualities from their birth.Although they do not bring them by birth they put some effort to practice them in life.They go through good and bad times to learn and practice these qualities.They learn from their life experiences.Their lives grow between success stories as well as failures.This is again a hard task.You need to learn the leadership qualities and put them in to practice as well.They are committed to  what ever the task they do."Leader is not a clock watcher."They have to make a choice to do all the work they in the most proper and accurate manner.They should learn everything starting from prioritizing work to managing to every other thing.
"Leadership is a game of forcuss."They need to learn to be forcussed.Attending to the tasks in a the most smart manner is one of the challengers they will have to face and succeed as well.Leader needs to be organized and well planned.A leader must protect his good name.
A leader must always measure her/his success and grab the points to be improved.Risks are dangerous though without taking risks you can never experience the success as well.So a leader must be able to take risks confidently and face them smartly.
To grow a leader or the quality you should create a good human in you.A good human being can be easily changed to a good leadr very easily.A good human with education makes it more easier to create a better leader.Then going through management trainings or work shops also can develop the leadership qualities in a person.
Remember leadership is a crown to your life either you get it from birth or you are made to be"