Business requirements

Overview

Business requirements in the context of software engineering or the software development life cycle, is the concept of 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

• Business context, scope, and background, including reasons for change
• Key business stakeholders that have requirements
• Success factors for a future/target state
• Constraints imposed by the business or other systems
• Business process models and analysis, often using flowchart notations to depict either 'as-is' and 'to-be' business processes
• Conceptual data models and data dictionary references
• Glossaries of business terms and local jargon
• Data flow diagrams to illustrate how data flows through the information systems (different from flowcharts depicting algorithmic flow of business activities)

Business requirements topics

Benefits

Roles

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

Both parties may be responsible for determining the business requirements and developing technical solutions. Business analysts tend to be involved in developing the implementation approach, and managing the impact on all business areas, including stakeholder engagement and risk management.

Format

:{| style="margin: 10px; width: 350px; float: right;" class="wikitable" |- ! Traditional BRD Structure - |- |

• Title
• Version
• Description of Change
• Author
• Date
• Contents
  1. Introduction
  2. Purpose
  3. Scope
  4. Background
  5. References
  6. Assumptions and constraints
  7. Document overview
  8. Methodology
  9. Functional requirements
  10. Context
  11. User requirements
  12. Data flow diagrams
  13. Logical data model / data dictionary
  14. Other requirements
  15. Interface requirements
  16. Data conversion requirements
  17. Hardware/Software Requirements
  18. Operational requirements
• Appendix A - |} 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) OR Technical Design Document (TDD) that details the design, technology performance and infrastructure expectations, including any technology requirements (non-functional) pertaining to quality of service, such as performance, maintainability, adaptability, reliability, availability, security, and scalability.

Completeness

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 the appropriate template use. Business requirements scope is not necessarily limited to the stage of defining what needs to be built as a business system. It goes beyond, to envisage how a running business system is managed and maintained, and to ensure its maintained alignment with 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 in focus.

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.

It is important to recognize the changes to requirements, document them, and keep the definition of requirements up-to-date. However, business requirements tend not to change nearly so much as the awareness of them. A business requirement may be present, but not recognized or understood by the stakeholders, analysts, and project team. Change is more apparent in regard to what is usually referred to as "requirements changes" - the product/system/software requirements. These tend to reflect the presumed ways of satisfying inadequately identified business requirements. Much of the difficulties attributed to achieving 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. This stems from failing to first adequately define 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. 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. They can foster standardized documentation regarding business requirements, which can facilitate understanding. Templates do not ensure accuracy or completeness of business requirements. In fact, commonly misused, templates often negatively impact requirement research, since they tend to promote superficiality and mainly mechanical definition without meaningful analysis.

Difficulties

References

• Beal, Adriana. Requirement is what we have to do to achieve an objective www.bealprojects.com, 2012
• Goldsmith, Robin F. Discovering Real Business Requirements for Software Project Success. Artech House, 2004.
• Robertson, Suzanne and James C. Robertson. Mastering the Requirements Process. 2nd Edition, Addison-Wesley, 2006.

References

1. Beal, 2012. page 1
2. Goldsmith, 2004. pages 2-6
3. "BRD template to document functional customer requirements".