Tips for Writing Excellent Business Requirements

Understand that the purpose of the business requirements document is to ensure that the design and development team has a clear and well-defined understanding of the tasks that are going to be automated, how those tasks fit into the organizational context, and who the role players are.

Ensure that the requirements analyst meets with the major stakeholders in the project for a series of meetings designed to flesh out the requirements of the system. Subsequent meetings may include secondary stakeholders and actual end users. This is to make sure that all roles are uncovered and properly documented.

The business requirements phase of the projects consists of these three steps:

Phase 1: Conduct meetings with all stakeholders and role players.

Phase 2: Assimilate all of the information that was gathered at the meetings.

Phase 3: Create the business requirements document.

Phase 1: Steps to conducting the business requirements meetings

1. Prior to the meeting the analyst should create a list of questions that will be asked of each stakeholder and user involved in the business requirements gathering process.

2. The analyst should note the answers to the questions and identify new issues that were not previously identified.

Phase 2: Steps to conducting the business requirements meetings

1. The analyst should summarize the information gathered at the meeting, prepare a report, and then create another question and answer form targeting the new issues that came to light in the previous meeting.

2. This process should continue until the analyst is able to produce a final report that everyone agrees encompasses all of the business requirements.

Phase 3: After the business requirements gathering phase is completed

1. The analyst prepares the formal business requirements document and presents it to all stakeholders for approval and signoff.

2. If signoff it received, the business analyst’s work is finished unless and until additional requirements are identified later in the software development cycle.

3. If signoff is not received then it is likely that the project will go back to Stage 1 for additional business requirements gathering and analysis.

Because the success of the projects depends upon it being built to the client’s specifications and expectations, the business requirements document is a key deliverable. This stage of the project should never be skipped in order to expedite the development cycle.

Failure to identify and document all business requirements creates unnecessary project risk that will be very difficult to mitigate later in the software development project lifecycle.

Posted in Uncategorized | Comments Off

Business Requirements – Learning and Analyzing Its Basics and Elements

Familiarizing and analyzing business requirements may seem to be a very critical task. Getting used to it may take some time, hard work and handful resources. As every new work, activity or project in the workplace needs to create a more positive response and outcome to address the needs of most if not all business operations. And to make these things favorably possible, businessmen and entrepreneurs must learn how to adhere to the calls of today’s business essentials.

One great way to go is to pass, maximize and take advantage of various business requirements. True enough, every business entity needs reliable and good business requirements in order to address its needs, demands and other issues – not to mention that this is necessary to make your business work for you favorably and productively. Indeed, to make it easier and much more convenient, practical and cost-effective, you might need to invest into some innovations and begin to venture out in every endeavor that you think would benefit your business.

Developing businesses definitely needs extensive and comprehensive business requirements, accurate business software and system requirements and the like. Everything has to be duly coordinated, accordingly communicated and effectively administered or implemented to its respective and corresponding functions and operations; otherwise, business projects might not seem to work on your end. Thus, this will create a domino effect that would neither be pleasant nor acceptable for you and you business.

Business project expectations run over time and require such enough budget. Information technology product management is aimed towards finding the right personnel, manpower, system and tools to make it work, including the basic things and key elements.

Complete, reliable and effective business requirements can really help business men and entrepreneurs like you to get rid of several problems and issues that may seem investable in any business entity or firm. Through the processes of discovering, analyzing, defining, and documenting such business requirements, which are intended to a specific business objective, business enthusiasts can begin maximizing all their means in many different ways – less risks, less worries.

With all these things, planning is a key element. As commonly defined in an academic context, planning is a process for accomplishing purposes, set in a specific objective towards the betterment of something. Also, it is termed as a blue print of business growth and a road map of development – helping you decide on objectives both in quantitative and qualitative terms. In this key process, setting of goals on the basis of objectives and keeping in the resources.

As an entrepreneur, it is important that you keep in mind your plans, goals and objectives – focusing mainly on your business desires and visions. And indeed, one great way to do this is to create a better and a more reliable business requirements analysis. Likewise, this helps you achieve this objective – leading you to better understanding and deeper perception towards your business needs.

Moreover, such detailed, accurate, efficient and specific business requirements that everyone agrees on have been believed to be the best way to eliminate business issues and heighten business growth. So, learn one today and see the difference. After all, business requirements can be a reliable virtual business partner.

Posted in Uncategorized | Comments Off

Business Requirements Analysis and Why It’s Important

Every project needs a business requirements specification document because it is the formal agreement between the client/end-users, the business owner/stakeholder and the project manager. It states exactly what will and will not be included in a project and what the end-user can expect once the project is completed. This is true for projects that are an extension of an existing status quo, such as enhancements to a software system, just as much as to projects involving brand new scenarios such as the development of new corporate policies.

Fully analysing your business requirements before embarking on a new project will lead, not only, to improvements but to a transformation of the business. So instead of ending up with a new business process, policy or system you could actually enable a substantial change in the business.

All new projects in the workplace are instigated in response to a business need or a business failing. Huge amounts of time and resources are usually expended to fulfil the business need but there is often a mismatch between what is delivered and what was actually needed. A thorough business requirements analysis can help to avoid this scenario by defining and clearly documenting the requirements for a specific business objective. It is the process that enables a clear and precise definition of the scope of a project and by breaking down the business needs into specific tasks it helps to assess the resources needed to complete the project.

Gathering Requirements

What are the best ways of getting started on the analysis process? Fortunately there are some well-recognised techniques for gathering the information needed in a Business Requirements Document. This list is not exhaustive but gives an overview of possible methods to use.

In all of these methods of gathering information, it is important to recognise that individuals from different business areas will only view the project from their own perspective and may not see the bigger picture. The analysis is intended to understand the different perspectives and document exactly what the project should achieve.

Brainstorming

Brainstorming is one of the best ways to produce lots of ideas on a particular topic in a short space of time. Set aside an hour in a relaxed environment with no distractions and invite people from all areas involved in the project. But keep the group to no more than 12 people for it to be most focussed and most effective.

The business analyst should encourage participation and a flow of ideas, which are written down on a whiteboard, flipchart, post-it notes etc. When there are plenty of thoughts, ideas and suggestions written down, the analyst then helps to determine which ideas are likely to provide the best solution and, therefore, require further discussion.

Storyboarding

Business Analysts use storyboarding to break down a project into small elements in order to focus on one element at a time. This helps to easily identify where information is lacking and where further analysis is required. It also helps in organising the work and communicating in unambiguous language to the end-users.

Interviews

Interviewing key personnel involved in the project is an extremely effective way of eliciting relevant information but it is important to interview the right people and also to make sure the interview questions stay focussed on the topic in question.

So before embarking on an analysis interview the questions should be prepared to ensure they are open questions (i.e. ones that require more than a one-word or brief answer) and that they cover the key points of: Function, Features, Preferences and User Expertise.

Prototypes

It is often difficult for people to visualise a product, process or system when it is completely new. So for projects which are not an extension of improvements of something that already exists, it is useful to produce a mock-up or model of the product or system to help end-users or clients to visualise what the final product will look like. Prototypes can help to identify inconsistencies, potential problems and usability issues.

Prototypes are most effective once some or all of the other techniques have been used to gather a full idea of the business requirements.

Interpreting the Requirements

Once all the requirements have been gathered and are documented at a high-level of detail it is necessary to determine which requirements can actually be delivered and which requirements are unnecessary to the fulfilment of the business objectives.

Some requirements are more important than others so they must all be prioritised to identify those which are fundamental to delivering a product, system or service and those which are “nice-to-have”.

It is also vital to assess the impact that the new project will have for existing processes and staffing skills and levels. For example, will members of staff need to be re-trained or will some roles become redundant?

Documenting the Detailed Requirements

Requirements must always be written down in language that is easy to understand, precise and unambiguous. Use simple language wherever possible, particularly if the document is not written in the first language of any of those who will be reviewing it. Avoid technical jargon whenever possible, but where it is necessary, clearly state exactly what a term means.

The document must contain sufficient detail that the new product, process or service can be created, tested and ultimately become a “live” product.

All of the requirements must be measurable or quantifiable and it must be possible to test the new product to verify that it meets the business objectives. Every individual task in the requirements document must contribute, even if indirectly, to the end result.

This check-list covers the basics of a Business Requirements Document but writing effective requirements using industry standards and best practices is a topic in its own right that is covered in detail on most project management courses:

Clear, unambiguous wording
Sufficiently detailed to create the product/process
Test cases and conditions can be easily defined
It is possible to achieve the desired final product/process
Design independent
Each requirement can be tracked in the final product/process
Every requirement is necessary to satisfy the business objectives.

Agreement and Sign Off

Before embarking in earnest on the project work it is vital that the project manager gets the signed agreement of the business requirements document from the stakeholders. This is their formal commitment that the document accurately and thoroughly describes the business needs.

Posted in Uncategorized | Comments Off

The Benefits of Documenting Business Requirements

Recently IT projects tend to underestimate the benefits of investing in developing comprehensive business requirements. Partnering with the business units upfront to define business needs has been proven to be the key to the success of an IT projects. You need to “know” what your business units “need” before you start building on the solution. On the contrary, common practice is that once the project is approved, all team members are eager to embark on the implementation of the solution.

We have all heard the usual: “… we all know what needs to be done, the business does not have the technical resources or knowledge for defining the requirements, everyone has developed projects so why the overhead of defining requirements, it is a waste of time etc etc.”…

One political strategy is pre-partnering. Clearly and comprehensively identifying user specifications and system requirements is key to project success. A thorough quality planning process (requirements gathering) is a critical success factor that is rarely given enough attention. One of the biggest reasons why IT projects fail is because project teams do not spend enough time in the trenches with front-line users,… To do this effectively, project managers must cultivate strong relationships between the IT project team, users, and stakeholders to ensure user needs and expectations are under constant focus and review. Source: Richard D. Lang [Project Leadership: Key Elements and Critical Success Factors for IT Project Managers]

In my view the five key benefits to having good and comprehensive business requirements are:

1. Better communication: Improves communication between team members and business owners through a formal requirements management planning process and offers a formal process for proposing and managing changes to requirements. It is an effective method of keeping stakeholders involved through the project lifecycle including design reviews, user acceptance testing, and deployment.

2. Lower cost: Significantly decrease costly rework and lowers project. Cost is managed reducing or eliminating unnecessary features and identifying significant flaws at the earliest possible time rather than after the system has been deployed.

3. Higher Value: Deliver higher value to the business. Clear definition of business objectives keeps the project team and stakeholders focused on delivering the value the business expects. Effective prioritization helps the business deliver real value, satisfies customer needs and enables the project team to fully understand and meet the needs of the customer as well as identification of missing requirements, ambiguities, and errors. It gives the opportunity to generate real improvements to the business units, not just change.

4. Lower Risk: Requirements significantly reduce the risk of project failure and provide the means to more accurately estimate timeframes and work estimates and control project scope. In addition to defining the scope of the project, the requirements document allows the project sponsors and board to clearly define and agree on what will and will not be delivered and what is expected from the successful completion of the project. It is like a “contract”, a formal agreement between the “client” and the project team.

5. On-time and quality: Deliver projects on-time. Provide the method for controlling and prioritizing requirements used to define accurate project schedules, underline the actual scope of the project and limit the probability of scope creep during project implementation. This allows for more accuracy in estimating timeframes and work estimates.

Alignment of requirements to business needs:

In order to maximize the benefits of requirements it is essential to remain aligned and keep the requirements updated during project implementation as there are many factors that may divert the defined requirements from the original. Project managers cannot afford to deliver in isolation; they need to be continuously involved with the business units and stakeholders to ensure that both business needs are kept aligned to the project delivery. Periodic reviews of requirements during the lifespan of the project ensure that the requirements are aligned to the continuously changing business needs.

On a final note, requirements will not only deliver business benefits that will be achieved by the project implementation, but will also considerably reduce cost, time and improve qualities which are the three main elements of IT project success.

Posted in Uncategorized | Comments Off

Are Business Requirements Important in IT Project Implementation?

Information Technology Projects within large organizations are frequently started in response to some business need or business failing. There is a tendency in organizations to seek funding and approval for project implementation through proposals based on high-level business needs. Usually proposals are attractive, inviting in appearance and are laid out in the form of a statement of work. They focus on the needs and objectives to be met and put emphasis on the persuasive factor of getting the project approved with the intent of “selling the project.”

A common approach is to proceed with the project implementation based on “the solution only” by defining the required resources, plan of action, deliverables, timelines, and estimated costs. The critical part of documenting business requirements is omitted and a brief list of very high level requirements is inserted to obtain funding and approval.

“The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements.” “Opinions about why projects are impaired and ultimately cancelled ranked incomplete requirements and lack of user involvement at the top of the list.” Source the Sandish Group report: Chaos.

The main goals of documented requirements should be to deliver value, reduce time and cost, increase satisfaction and achieve success. In my experience, the three integral aspects that are necessary for the success of projects, but that are often missed out or not detailed enough, are:

1. Benefits and business value:

People lose focus of the project’s benefits and sponsors do not commit to measuring and achieving the defined benefits. It is very difficult to achieve business value if there is lack of commitment to attain the defined benefits. The benefit statements should be clear, concise, and quantified.

2. Detailed business requirements:

Documented requirements are Important!!! In order to align the solutions for delivery of business value, the business requirements must be captured and the solution must be managed to meet them. In my opinion business requirements should be S.M.A.R.T., namely Specific, Measurable, Achievable, Results-focused and Time-bound. Furthermore the solution should be designed to satisfy and comply with organizations enterprise architecture.

3. Documented quality assurance processes:

The lack of detailed requirements creates a huge problem for the Quality assurance team that is expected to ensure the quality of the project as a whole. The quality assurance team needs to have the means to compare what was delivered, to what was required. The more detailed the requirements are, including what is the proof of success, the more likely quality could be achieved.

Findings from surveys of over 100 companies in Keith Ellis’s report: “The Impact of Business Requirements on the Success of Technology Projects” determined that “Companies with poor business analysis capability will have three times as many project failures as successes. 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of: Taking over 180% of target time to deliver; Consuming in excess of 160% of estimated budget; Delivering under 70% of the target required functionality. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. Over 40% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization. The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.”

One must always remember that people in different roles will view the project from their own perspective and will not always see the bigger picture. A consolidation phase of requirements analysis needs to be done to look at these different perspectives and present an overall holistic best solution.

In FAO gathering business requirements is performed through brainstorming sessions with the business units and/or defining phased deliverables to be used as prototypes. The Information Technology Division in FAO has put in place mechanisms for ensuring Quality Assurance involvement in all phases of project implementation, from the project inception to project closure phases. In addition, emphasis for all IT projects to measure benefits and liaise with our business units to develop detailed business document requirements has become a prerequisite to project approval. In 2015 the IT division will measure the rate of improved project delivery due to increased business requirements definition.

In Karl E. Wiegers presentation, the “Cosmic Truths about Software Requirements” the following points are some key points to remember:

If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project; Requirements development is a discovery and invention process, not just a collection process; The interests of all the project stakeholders intersect in the requirements process; The first question an analyst should ask about a proposed new requirement is “Is this requirement in scope?”; The requirements might be vague, but the product will be specific.

On a final note, as considerable resources in terms of people and money are used to deliver what is actually needed for the realization of the expected business value and objectives, good business requirements are instrumental to avoid failures and complete successful projects.

Posted in Uncategorized | Comments Off