Business requirements

Business requirements are what must be delivered to provide value. Products, systems, software, and processes are the ways how to deliver, satisfy, or meet the business requirements whats. Consequently, the topic of business requirements often arises in the context of developing or procuring software or other system; but business requirements exist much more broadly. That is, 'business' can be at work or personal, for profit or non-profit.

Confusion arises for three main reasons. (1) A common practice is to refer to objectives, or expected benefits, as 'business requirements.' [1] (2) People commonly use the term 'requirements' to pertain to the features of the product, system, software expected to be created. (3) A widely held model says these two types of requirements differ only in level of detail or abstraction—wherein 'business requirements' are high-level and vague and decompose into product, system, or software requirements that are detailed.

Such confusion can be avoided by recognizing that business requirements are not objectives but rather meet objectives (i.e., provide value) when satisfied. Business requirements whats do not decompose into product/system/software requirements hows. Rather, products and their requirements represent a response to business requirements—a way how presumably to satisfy the whats. Business requirements exist within the business environment and must be discovered, whereas product requirements are human-defined (specified). Business requirements are not just high-level but need to be driven down to detail. No matter how far down in detail they are driven, business requirements are always business deliverable whats that provide value when satisfied; driving them down to detail never turns business requirements into product requirements.[2]

In system or software development projects, business requirements usually requires authority from stakeholders. This typically leads to the creation or updating of a product, system, or piece of software. The product/system/software requirements usually consist of both functional requirements and non-functional requirements. Although typically defined in conjunction with the product/system/software functionality (features and usage), non-functional requirements often actually reflect a form of business requirements which sometimes are considered constraints, such as necessary performance, security, or safety that apply at the business level.

Business requirements are often listed in a Business Requirements Document or BRD. The emphasis in a BRD is on what is required, rather than on how to achieve it, which is usually delegated to a Systems Requirements Specification or Document (SRS or SRD) or other variation such as a Functional Specification Document. While supposedly describing the product, system, or software from an external perspective, such documents often define the product/system/software requirements in the context of a chosen technology (a solution approach or architecture). Further confusion often arises when people writing BRDs do not understand the distinctions; and consequently many BRDs actually describe requirements of a product, system, or software.

Overview

Business requirements in the context of software engineering or the software development life cycle, is about eliciting and documenting business requirements of business users such as customers, employees, and vendors early in the development cycle of a system to guide the design of the future system. Business requirements are often captured by business analysts, who analyze business activities and processes, and often study As-is process to define a target To-be process.

Business requirements often include[3]

Business requirements topics

Benefits

Benefit [4] Description
Reduce Project failure Structured explanation of a business process or method defined early in the life cycle helps reduce project failures that occur due to misaligned or misrepresented requirements leading to failure of user expectations.
Connects to broader business goals Well-defined business requirements help lay out a project charter, a critical step in executing business strategy or business goals, and to take it to the next logical step of developing it into an IT system. This helps monitoring overall project health and provides for positive traction with key project stakeholders including sponsors.
Consensus creation and collaboration The benefit of a structured format typical of business requirements documentation helps create positive consensus and better collaboration where the business stakeholder group might be a large cross-functional team, distributed geographically.
Saves costs Good quality of business requirements when captured early on not only improves success of a project but also save overall costs associated with change requests, and related investments in training, infrastructure, etc.

Roles

Business requirements are typically defined by business analysts in collaboration with other project stakeholders.

Responsible for scoping the business requirements and developing technical solutions. Involved in developing the implementation approach and managing the impact on all business areas. Responsible for all aspects of the project from business analysis to plan management, stakeholder engagement and risk management.

Format

Traditional BRD Structure - [5]
  • Title
  • Version
  • Description of Change
  • Author
  • Date
  • Contents
    1. Introduction
      1. Purpose
      2. Scope
      3. Background
      4. References
      5. Assumptions and constraints
      6. Document overview
    2. Methodology
    3. Functional requirements
      1. Context
      2. User requirements
      3. Data flow diagrams
      4. Logical data model / data dictionary
    4. Other requirements
      1. Interface requirements
      2. Data conversion requirements
      3. Hardware/Software Requirements
      4. Operational requirements
  • Appendix A - Glossary

The most popular format for recording business requirements is the Business Requirements Document (BRD). The intent behind the BRD is to define what results would be wanted from a system, however it might eventually be designed. Hence, BRD documents are complemented with a systems reference document (SRD) that details the technology performance and infrastructure expectations including any technology requirements pertaining to quality of service, such as performance, maintainability, adaptability, reliability, availability, security, and scalability....

Completeness

One can never be absolutely certain that business requirements are accurate and complete. However, then there are more than 50 ways to evaluate requirements adequacy and thereby increase confidence in their accuracy and completeness. The more of these methods that are used, and the greater skill and proficiency with which they are used, the more accurate and complete the requirements are likely to be. Unfortunately, there are a number of widely held misperceptions about effectiveness of various methods for evaluating business (and product/system/software) requirements. The following paragraph and those in the subsequent section have been left in this article because they exemplify some common misconceptions, which are addressed after the next paragraph.

Prototyping with early stage testing can assess the completeness and accuracy of captured business requirements. Stakeholders come in early to help define the requirements, and the result is sent to the project development teams who build the business system; other stakeholders test and evaluate the final deployed system. Clarity requires keeping track of the requirements and their solution, with a formal process for determining which template to use, determining to who fills what section, and who modified next and released which version. Business requirements scope is not necessarily limited to the stage where it serves to define what needs to be built as a business system. It goes beyond to envisage, how a running business system is managed and maintained, to ensure it stays aligned to business goals or strategy. A business requirements document needs to be constantly revised, in a controlled fashion. Having a standardized format or templates that are designed for specific business functions and domains can ensure completeness of business requirements, besides keeping the scope fixed and clear.

Although commonly considered a means of evaluating requirements, prototyping actually usually shifts attention from business requirements to the product, system, or software being built. Prototypes are working software, which means they are three steps (product/system/software requirements, engineering/technical design of said product/system/software, and implementation of the design in program code) removed from business requirements. Prototypes are preliminary versions of the software the developer intends to implement. Because prototypes are fairly concrete, stakeholders who try out the prototype can give more meaningful feedback regarding some aspects of what the developer is creating, which is the developer's interpretation of a way to satisfy business requirements, not the business requirements. Moreover, in order to create a prototype early and quickly, the Graphical User Interface (GUI) is emphasized and the "guts" are shortcut. The guts are the bulk of the program logic and are where most business requirements would be addressed. In other words, issues that prototypes reveal are very unlikely to involve business requirements.

Indeed it is important to recognize requirements changes, document them, and keep the definition of requirements up-to-date. However, business requirements tend not to change nearly so much as awareness of them. That is, the business requirement was there all along; but it was not recognized or understood by the stakeholders, analysts, and project team. What does change much more, and what usually is referred to as "requirements changes," are changes to the product/system/software requirements—usually because they reflect presumed ways of satisfying inadequately identified business requirements. Much of the difficulties attributed to business requirements in fact reflect the common practice of devoting almost all "requirements" effort to what is actually high-level design of a product, system, or software without adequately first defining the business requirements the product/system/software must satisfy in order to provide value. Development practices commonly keep revising the product/system/software until they eventually "back into" a solution that seems to do what is needed, i.e., apparently addresses a business requirement. Ironically, such costly trial-and-error indirect ways of identifying business requirements are the basis for much of "iterative development," including popular Agile development methods, that are touted as "best practices."

Templates help prompt inquiry regarding particular topics that often may be relevant to business requirements; and templates can foster standardized documentation regarding business requirements, which can facilitate understanding. Templates do not ensure accuracy or completeness of business requirements. In fact, templates often negatively impact requirements because they tend to promote superficiality and mainly mechanical definition without meaningful analysis.

Difficulties

Business requirements are often prematurely hardened due to the large stakeholder base involved in defining the requirements, where there is a potential for conflict in interests. The process of managing and building consensus can be delicate and even political by nature. A lesser challenge, though common, is that of distributed teams with stakeholders in multiple geographical locations. It is natural that sales staff is closer to their customers, while production staff is closer to manufacturing units; finance and HR, including senior management are closer to the registered headquarters. A system for example that involves sales and production users may see conflict of purpose – one side may be interested in offering maximum features, while the other may focus on lowest cost of production. These sorts of situations often end in a consensus with maximum features for a reasonable, profitable cost of production and distribution.

To address these challenges, early stage stakeholder buy-in achieved through demonstration of prototypes and joint working. Stakeholder workshops are common, either as facilitated sessions or simple huddled discussions help in achieving consensus, especially for sensitive business requirements and where there is potential conflict of interest. Complexity of a business process is a factor of such interest conflicts among stakeholders or due to an inherently complex business process, such as one where there is much specialized knowledge required to comprehend legal or regulatory requirements, internal company wide guidelines such as branding, corporate commitments to social responsibility, and the like. Business requirements analysis is not just about capturing the ‘what’ of a business process along with its ‘how’ to provide context; in addition it is about how the business requirements get translated into designing and building a working system. At this stage, business requirements have to acknowledge and supplemented with technical details and feasibility.

Not always is a custom-built solution required for every new set of business requirements. There are often standardized processes and products, which with some tweaking or customization, can serve to address the business requirements. Often the target business system is constrained by a specific technology choice or a budget or available products already deployed.

Finally, the purpose of standardizing on a format to capture business requirements. Best is if there is standardization for a given industry, but standardizing within an organization is a minimum necessity.. Multiple projects with multiple formats that lead to variation in structure and content of a requirements document renders these ineffective from a traceability and manageability perspective. In fact, when creating a template for use in a cross-functional requirements gathering exercise, different roles with complementary knowledge may find it difficult to work with a common format. Therefore it is important to allow non-specialist or non-expert stakeholder to provide additional requirements by Appendices and additional attachments to cover their area of specification. Addressing various nuances and arriving at a best fit remains the single biggest challenge to effective requirements.

See also

Bibliography

References

  1. ↑ Beal, 2012. page 1
  2. ↑ Goldsmith, 2004. pages 2-6
  3. ↑ Multiple (wiki). "Software requirements". Docforge. Retrieved 2013-07-31.
  4. ↑ http://www.scribd.com/doc/6766319/Business-Requirements
  5. ↑ http://infor.ittoolbox.com/groups/strategy-planning/baan-projectmanagement/brd-template-to-document-functional-customer-requirements-2081133

4. http://www.techiesbytes.com/2013/04/how-to-write-good-business-requirement.html