Procuring quality business requirements is an important step toward the design o

Question

Procuring quality business requirements is an important step toward the design of quality information systems. Completion of a quality requirements document allows user needs and expectations to be captured, so that infrastructure and information systems can be designed properly. Your company, which is a data-collection and analysis company that has been operating less than two (2) years, is seeking to create a repository for collected data beyond standard relational databases. Your ten (10) terabyte data warehouse is expected to grow by 20% each year. You are mindful of data warehousing best practices which will aid you immensely in your requirements gathering effort. Using the requirements document provided in the course shell, you are to speculate on the needs of the company. You must consider current and future requirements; however, assumptions should be realistic and carefully considered.

Explanation / Answer

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.

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 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 bybusiness analysts, who analyze business activities and processes, and often study As-is process to define a target To-be process.

Business requirements often include

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

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..

TRADITIONAL BRD STRUCTURE

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

Related Questions

Navigate

• Browse (All)
• Browse P
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.