Business requirements - AbsoluteAstronomy.com

Business requirements is about creating structured representations of business activities, used to communicate how a new or existing business process should work. In IT projects business requirements is often a precursor to designing and building a new business application/system, or changing an existing one, and often sets the context for business process modeling

Business process modeling

Business Process Modeling in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed and improved. BPM is typically performed by business analysts and managers who are seeking to improve process efficiency and quality...

, requirements analysis

Requirements analysis

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...

. The business requirements may encompass pre-requisites for both functional requirements

Functional requirements

In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs ....

and non-functional requirements

Non-functional requirements

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or...

that are desirable in the new or to be changed system. Business requirements are fairly standardized in their content structure and often referred to as Business Requirements Definition document or BRD. The emphasis in a business requirement document is on business processes and analysis outlining required change, and less on how to achieve using IT development. However, since IT based solution to deploying a new business requirement is common and may be required to work with existing IT systems and IT infrastructure, business requirements may therefore be accompanied by what is popularly referred to as Systems Requirements Definition or SRD or Systems Requirements specification, which complements the business requirements, and defines the technology related requirements.

Overview

Business requirements in the context of software engineering or software development life cycle, is about eliciting and documenting business requirements of business users such as customers, employees, vendors, etc. early in the development cycle of an information system to specifically design and develop the future business system. Capturing business requirements is often carried out by business analyst

Business analyst

A Business Analyst analyzes the organization and design of businesses, government departments, and non-profit organizations; BAs also assess business models and their integration with technology.-Levels:...

s, 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 and background, including reasons for change
Key business Stakeholders requirements
Business process models and analysis using standard flowchart notations to depict business processes (as-is and to-be)
Logical data model and data dictionary references
Data flow diagrams to illustrate how data flows through the information systems (different from flowcharts depicting algorithmic flow of business activities)

Benefits

Benefit	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 captured or owned by business analyst

Business analyst

s, often in collaboration with other stakeholders, which include subject matter experts, customers, end users, technology architects

Enterprise architect

Enterprise architects are practitioners of enterprise architecture; an information technology management discipline that operates within organizations.-Role of enterprise architects:...

, ethnographers and user surveyors, usability experts

Usability

Usability is the ease of use and learnability of a human-made object. The object of use can be a software application, website, book, tool, machine, process, or anything a human interacts with. A usability study may be conducted as a primary job function by a usability analyst or as a secondary job...

, UI designers and in some cases senior management executives who directly sponsor such activities. Experts with business knowledge, industry domain knowledge, and technical knowledge are especially critical to elicit and define business requirements, including conducting business analysis. Often for a project there is a project sponsor and a project charter, which defines scope of business requirement. Typically, a business analyst owns the business requirements and manages them over time. Business analysts are usually like internal or in-house consultants.
Different bodies representing business analysts have different models defining essential competencies of business analysts, which broadly cover

communication skills,
industry and business knowledge,
tools and methods of analysis and management.

Format

Typical BRD Structure -
Title Version Description of Change Author Date Contents Introduction 1.1 Purpose 1.2 Scope 1.3 Background 1.4 References 1.5 Assumptions and constraints 1.6 Document overview Methodology Functional requirements 3.1 Context 3.2 User requirements 3.3 Data flow diagrams 3.4 Logical data model / data dictionary Other requirements 5.1 Interface requirements 5.2 Data conversion requirements 5.3 Hardware/Software Requirements 5.4 Operational requirements Appendix A - Glossary

The most popular format to capture business requirements is what is popularly referred to as business requirements document (BRD). The intent behind these sorts of descriptive documents is to help automate either parts or the entire business process into an IT system. 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, be it performance, maintainability, adaptability, reliability, availability, security, scalability etc. Often, the BRD specifications are also referred to as functional requirements, while the technology related aspects as non-functional requirements. These standard formats are captured using popular templates such as BRD, SRD/SRS, Use Cases, Flow charts, data flow diagrams, some complementing the other. There are a variety of tools to carry out each of these modeling activities.

At a broader level, format and standardization could pose difficulties if it is not structured for a specific business problem or area. Again, it needs to have sufficient flexibility that allows an author to customize the format, without deviating from the need to provide consistency, traceability, usefulness and without breaking down the larger business goals, especially in the case of complex, cross-functional business situations. There is the risk of misinterpretation of textual content that leads to mismatch of end deliverable and initial expectations. Retaining context and supplying relevant background descriptions is a critical part of these formats. While a majority of templates use a structured format, a few others use story telling as a way to capture scenarios to fully capture finer nuances of a complex business process, which otherwise tend to get ′lost in translation′ when overburdened with structure.

Tools

Category	Tools
Document	Microsoft Office Microsoft Office Microsoft Office is a non-free commercial office suite of inter-related desktop applications, servers and services for the Microsoft Windows and Mac OS X operating systems, introduced by Microsoft in August 1, 1989. Initially a marketing term for a bundled set of applications, the first version of... (Word, Excel, PowerPoint), Openoffice, etc.; Wordpress WordPress WordPress is a free and open source blogging tool and publishing platform powered by PHP and MySQL. It is often customized into a content management system . It has many features including a plug-in architecture and a template system. WordPress is used by over 14.7% of Alexa Internet's "top 1... blog tools, etc.; Social tools - Facebook Facebook Facebook is a social networking service and website launched in February 2004, operated and privately owned by Facebook, Inc. , Facebook has more than 800 million active users. Users must register before using the site, after which they may create a personal profile, add other users as... , Twitter Twitter Twitter is an online social networking and microblogging service that enables its users to send and read text-based posts of up to 140 characters, informally known as "tweets".Twitter was created in March 2006 by Jack Dorsey and launched that July... , Email - Outlook Outlook Outlook or The Outlook may refer to:In computing* Microsoft Outlook, an e-mail and personal information management software product from Microsoft* Outlook Express, an e-mail and news client bundled with certain versions of Microsoft Windows... , Eudora Eudora Eudora may refer to:PlacesEudora, Arkansas, a cityEudora, Kansas, a cityEudora Township, Douglas County, KansasEudora, Mississippi, an unincorporated communityEudora, Missouri, an unincorporated community217 Eudora, an asteroidOther... , Thunderbird Thunderbird -Creatures:* Thunderbird , a legendary creature in Native American culture* Dromornithidae, an extinct Australian family of birds* Thunderbird , a term used in cryptozoology to describe large, bird-like creatures-Computing:... , etc.; Online docs - Google docs, Scribd Scribd Scribd is a Web 2.0 based document-sharing website which allows users to post documents of various formats, and embed them into a web page using its iPaper format. Scribd was founded by Trip Adler, Tikhon Bernstam, and Jared Friedman in 2006... , Slideshare SlideShare SlideShare is a Web 2.0 based slide hosting service. Users can upload files privately or publicly in the following file formats: PowerPoint, PDF, Keynote or OpenOffice presentations. Slide decks can then be viewed on the site itself, on hand held devices or embedded on other sites. Launched on... , etc.;
Flowchart Flowchart A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these...	Microsoft Visio Microsoft Visio Microsoft Visio , formerly known as Microsoft Office Visio, is a commercial diagramming program for Microsoft Windows that uses vector graphics to create diagrams.- Features :... (with UML Unified Modeling Language Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group... add-in); PowerPoint, etc.
Business process modeling Business process modeling Business Process Modeling in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed and improved. BPM is typically performed by business analysts and managers who are seeking to improve process efficiency and quality...	Rational Requisite Pros and Rational Rose (from IBM), Business Process Architect (from Visual Paradigm), EA (from Sparx Systems)
Painting and image tools	Adobe Illustrator Adobe Illustrator Adobe Illustrator is a vector graphics editor developed and marketed by Adobe Systems. Illustrator is similar in scope, intended market, and functionality to its competitors, CorelDraw, Xara Designer Pro and Macromedia FreeHand.... , Photoshop, Corel Draw, etc.
Prototyping/Mockup/Wireframing	Axure RP Axure RP Axure RP Pro is a wireframing, rapid prototyping, and specification software tool aimed at web and desktop applications. It offers capabilities typically found in diagramming tools like drag and drop placement, resizing, and formatting of widgets... , iRise IRise iRise is a software company based in El Segundo, California. It provides visualization software for business applications.-History:Founded in 1996 by Maurice Martin under the name of Intrasolv Consulting. Co-Founder Emmet B. Keeffe III joined in 1998... , Serena Serena Software Serena Software Inc is US-based software company.Serena develops and markets products focused on managing change across information technology environments... , ProtoShare ProtoShare ProtoShare is a collaborative software tool from Site9, Inc. used for creating, reviewing, and refining website and web application prototypes. It enables individuals and companies to visualize project requirements by building website wireframes and application prototypes that team members and... , LucidChart LucidChart LucidChart is a web-based diagramming software. This software is notable because it is built on web standards such as HTML5 and Javascript and provides real-time collaboration for the creation of graphical content... .
Requirements management and Business Analysis	Test Director (for Traceability), Rational Suite from IBM (end to end requirements management suite), HP Quality Center (for test cases and testing), Psoda (Cloud based requirements management tool)

Completeness

Prototyping with early stage stakeholder testing is an important way to assess the completeness and accuracy of captured business requirements. Especially since various stakeholders who help define requirements come in early and hand over to project development teams who build the business system, and others who test and evaluate final deployed system or working solution, it is very important to have traceability of requirements. Hence a well administered process to control the entire process of business requirements, right from which template to use to who fills what section and when, who modified next and released as which version, etc. is an important aspect of managing business requirements. 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. In that sense, a business requirements document can be viewed as a living document, meaning it is constantly revised, albeit, in a controlled fashion. Also, 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.

Challenges

Business requirements are often stuck due to 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 often 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 head quarters. 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.

Some common solutions that address these challenges include, early stage stakeholder buy-in achieved through demonstration of prototypes and jointly working to co-create, etc. Stakeholder workshops that are either 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 therefore a factor of such interest conflicts among stakeholders or due to an inherently complex business process, such as one where there is a lot of specialized knowledge required to comprehend viz. legal, regulatory requirements, even internal company wide guidelines such as branding, corporate commitments to CSR, etc. Business requirements is not just about capturing the ‘what’ of a business process along with its ‘how’ to provide context, in fact, in addition to the what and how, it is also about how the business requirements get translated into designing and building a working system. Here, at this stage, business requirements have to acknowledge and supplemented with technical details and feasibility. Not always do you have a solution built custom for every new set of business requirements. There are often standardized processes and products which with some tweaking or customization serve to address the business requirements. The challenge is when the target business system is constrained by a specific technology choice or a budget or available products already deployed. Last, but not the least, is the challenge of standardizing on a format to capture business requirements. If not achieve standardization for a given industry, at the very best, standardizing within an organization can be a challenge. 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. Here, it is important to ensure, it is understood by non-specialist or non-expert stakeholders, at the same time, allow via Appendices and additional attachments for experts to dive into their area of specification. Addressing various nuances and arriving at a best fit remains the single biggest challenge to effective requirements.

Prototyping

Creating pictorial representations and interactive simulations with images, wireframe layouts and interactive, clickable prototypes can help cut the noise arising out of interpreting textual descriptions. Also, visual modeling of requirements via prototyping, etc. portrays a WYSIWYG real feel to an application and helps create consensus more rapidly. Prototypes are often created as mockups and wireframes which might be just snapshot views, static representations. Dynamic, realistic prototypes traditionally require some amount of programming effort to create a more detailed, interactive and richer prototype of the application. The choice between a quick and dirty paper prototype on one hand and a completely finished WYSIWYG interactive prototype is based on the sensitivity and need of stakeholders involved. For a simple business requirement with fairly straightforward processes and low in complexity, a quick and dirty prototype serves the purpose. For more sensitive business requirements where there is a likely political angle to stakeholder interests or well known viewpoints, or complexity of process, a more detailed, dynamic prototype is more appropriate. The challenge to prototyping is often the time required and cost of prototyping effort, especially to create high-fidelity prototypes (also see low-fidelity prototypes).
In practice, however, not every project’s business requirements are supported by prototypes, especially detailed, clickable prototypes. Primary reasons for not doing prototypes, especially the detailed, interactive one requiring custom development effort, is either it takes too much effort and time, nullifying the basic premise of early buy in or evaluation.
Prototypes often tend to be used primarily to demonstrate user experience, but doesn’t capture underlying business logic or rules. Process flows to illustrate business activities is often captured separately using flowchart style layouts. Screen prototypes and mockups complement these flowcharts depicting business activities. Additional simulation using dummy data or duplicate systems is also used to validate and demonstrate business rule behavior, which is often not visible to end users or is underneath the click of a button, or how a tabular chart loads with what data using what layout. Business process simulation is an area in its own right and is not within scope of prototyping. There are full-fledged XML variant business process languages and engines to run these. However, it is pertinent to mention these aspects of simulation to highlight the complete extent and scope of a business requirements document.