How to Capture Nonfunctional Requirements

Information Management published this week a nice post entitled How to Capture Nonfunctional Requirements, written by Sastry Kolluru and Shantaram Nishtala, where they commented about an important issue: the nonfunctional requirements gathering.

The business users define the functional requirements substantially well but are challenged when detailing nonfunctional requirements. Asking business the right questions can achieve a better business-IT alignment, they wrote. In a typical data integration initiative, it is not uncommon that functional requirements may not be completely defined early in the project lifecycle; they get clarified as the project progresses. The clarity on nonfunctional aspects is much lower. NFRs are stated informally during the requirements gathering, are often contradictory, difficult to enforce during software development and hard to validate when the software system is ready for delivery.

They listed some reasons because the nonfunctional requirements seem less clear:
- There’s a lack of understanding about what to include as nonfunctional requirements;
- No one is sure what should be specified, this results in exclusion or specification of unrealistic nonfunctional requirements; and
- People assume it is implicit.

They defined some key questions that could be used to define Nonfunctional Requirements in some areas: Performance, Scalability, Reliability, Maintainability, Extensibility, Security and Resource Utilization.

Effectively gathering NFRs is a key success factor for all data integration initiatives. Understanding the types of NFRs and following a systematic approach for capturing them can help identify quantifiable and measurable NFRs, they concluded.

A requirements gathering (functional and nonfunctional) is a vital step to develop a succesful data integration initiative. You should understand well what the business users need, the difference between mandating “what” versus “how” and also define a transparent process to follow through the entire project lifecycle.

Requirements Gathering: Don't Be Naïve

Today, Neil Raden (Smart Enough Systems) wrote an interesting article in Intelligent Enterprise, called Requirements Gathering: Don't Be Naïve.

In the article, he talks about what he thinks be wrong in the issue of business requirements gathering.

He has an interesting point of view and made me think about this issue. I agree with him when he said: "use experienced people who already have a good handle on what organizations like yours have done successfully", but I also know that is increasingly more difficult to find experienced people with those skills.

I think nowadays one of the most important challenges in BI projects is to find experienced people that have good skills to do the important work of business requirements gathering.

The Profit Impact of Business Intelligence

The Profit Impact of Business Intelligence - Steve Williams and Nancy Williams

In this book, Steve and Nancy Williams focused on to show the side business of Business Intelligence, explain that the BI is not mainly about technology and also how the companies should looking for to use the BI to improve profit and performance.

The book is organized in three parts, in the Part 1: Identifying and Leveraging BI-Driven Profit Opportunities, they introduce the terms of BI, show the BI opportunity analysis, and also key barriers and business risk.

The Part 2: Creating the BI Asset, they provide a business and technical overview that how to design, build, deploy, and leverage a BI environment, using what they called the BI pathway method, and how the BI should be business-oriented.

The Part 3: Leveraging BI for Profit Professional, they define more deeply how companies have used BI in different ways to drive profits.

All the chapters have in the end two sections: Key Points to remember and Think Tank, where they summarize the chapter, define tips and make questions about the subject of the chapter.

The authors wrote a very good book, where they show the direction to improve how the companies use the BI to achieve their strategic goals.

Business Requirements for BI

Steve Williams wrote a nice piece called Business Requirements for BI and the BI Portfolio: How to Get it Right, this month, in the DM Review.

He starts mentioning three primary deficiencies in generic BI requirements, traditional report requirements and functional specifications:

- They do not provide the basis for a compelling business case that business leaders buy into, one that clearly articulates how BI will be used within specific business processes to improve business performance.
- They do not provide enough specificity with respect to the kinds of BI applications that are needed, whereas BI is a broad term that encompasses a wide range of applications, from basic reporting and OLAP to sophisticated analytics.
- They do not provide enough specificity to guide development of the BI databases and applications that deliver the BI or to guide the business process changes that deliver the bang for the buck to the business.

He also explains the Weakness of generic BI business requirements and why BI functional requirements are not enough.

He defines a well-structured set of BI business requirements:

- Establishes a clear linkage between business strategies, the core business processes via which the strategies are executed and BI-driven business improvement opportunities (BIOs), which are the basis for a BI business case that is compelling to the business stakeholders;
- Identifies and clearly describes what business information, analytic tools and techniques, and decision support is required by the business to realize BI-driven improvement opportunities regarding management processes, customer processes and/or operational processes;
- Provides the essential input to the process of defining specific BI projects and prioritizing those projects based on key criteria such as business impact and time to market;
- Provides the means of aligning BI, business process improvement and balanced scorecard initiatives;
- Drives key data architecture decisions;
- Provides the basis for end-to-end traceability between BI requirements approved by business users and the delivered data stores and BI applications; and
- Provides a key baseline against which the performance of the BI initiative can be measured.

In my opinion, well-defined business requirements is one of the most important factors of success in an BI project.

Steve Williams also wrote a good book, with Nancy Williams, called:
The Profit Impact of Business Intelligence