Requirements Definition

Requirements Definition
Analytical Specification and Design

There are two major components to any requirements definition project: defining the user requirements (including content and analyses), and tracing the available data sources from the end users back to the original data-generating events. DSS Lab has a unique approach to both.

User Requirements
Analytical Specification & Design

User requirements are an indispensable tool for communication between users, developers, and managers whether that communication takes place before, during, or after development. Of course, the better the requirements are refined prior to development, the greater the likelihood and scope of success are during the development and deployment. Requirements do evolve over time, and like any other phase and artifact of a project need to be managed carefully. The greater their clarity and precision, the easier it is for all parties involved to agree on what needs to be done, or needed to be done.

At DSS Lab we recognize that many genuine user requirements do not surface through passive interviews and questionnaires. This is one of the challenges of defining user requirements for decision support or analytical solutions. Thus, we treat the user requirements definition as an iterative process. After some initial discussions with representatives of each reasonably homogeneous group of users (which is likely to include a substantial briefing on how things are currently done), we show or propose solutions to each group and elicit more qualified preferences from the users. This process either converges to a solution (the requirements) or shows the existence of substantially different, possibly conflicting, requirements the resolution of which typically needs to come from a senior level. In the latter case, building consensus towards a unified set of requirements is an important step.

At DSS Lab, we also recognize that although it is popular to speak about actionable information (which is just a fancy way of saying "decision supporting"), as if so-called actionable information needed to pass a single test, that there are in fact two distinct types of information that need to be included in any comprehensive set of user requirements:

1. Known decision supporting information

This is the kind of information most frequently called actionable and is the easiest to ferret out during the requirements phase and could encompass, for a sales and marketing application, sales forecasts, revenue per employee, cumulative sales to date, and so on.

2. Information that represents purposeful understanding

This kind of information, since it is not immediately actionable, is often left out of requirements documents. It needs more active probing to reveal these subtle information requirements. However, purposeful understanding is just as crucial as known decision supporting information because it defines the context for users relative to which decisions are thought about and made. For a sales and marketing application it could include sales tracking for similar - but not perceived as competitive products, the temporal evolution of key feature changes in the market, the ratio of product sales for the category as a whole to some of its parent and sibling categories, the temporal evolution of the count of press releases for sales wins and for new products or enhancements and so forth. Such metrics or indicators are sometimes recognized as important benchmark indicators, but often are ignored.

Therefore, as part of a requirements collection and design of decision-supporting analyses, we work at a strategic level to ensure maximal useful information coverage as well as at a managerial level for development and refining.

Not only does DSS Lab have a unique approach to defining requirements, we have also developed a uniquely powerful mathematical language (Type Language, as used throughout Erik Thomsen's OLAP Solutions, Second Edition) for exactly specifying user information requirements regardless of the brands (Oracle, Microsoft, SAS, IBM, etc.) or types of analytical software (relational, OLAP, data mining, etc.) involved in the existing or envisioned decision support system. With our language and our processes, we can seamlessly connect end user views and interactions, calculations and selections in any software tier, data and processing distribution among computing resources, security and access controls, and source data structures and events.

The combination of techniques for marrying strategy to analytics and techniques for clear representation of system requirements provide our customers with the basis for a cleanly designed and implemented solution.

Data sources

DSS Lab also has a unique method when it comes to source data identification. Not only do we advocate tracing the data sources from the point at which they are identified by users (their relative source) all the way to the beginning of their electronic form (such as from two data marts to a single data warehouse through an ETL environment to a staging area to transaction database) but at DSS Lab, we strongly advocate the documenting of the actual data generating events for which the data in the transaction (or other) systems may only represent a subset of the measurable attributes of the events.

We make use of DEER cycle analysis to accomplish this goal. We have published the approach in a series of articles in Intelligent Enterprise magazine (part 1, part 2, part 3).

By tracing source data all the way back to the data generating events we can

· Create a set of fully connected causal links between the information defined in the user requirements, the decisions taken as a result of that information, the execution of those decisions, the environment or world impact of those executed decisions (which are the data generating events) and finally the measurement of those events as captured in electronic form.

· Identify aspects of the data generating events that need to be captured to support decisions that need to be made,

· Identify data generating events that are caused by the execution of decisions made with the information we are generating in the application that are not even being tracked and

· Design statistically significant experiments to collect decision-supporting data that allows us to define optimal decisions per whatever criteria we choose.

Since the entire application is embedded within a DEER cycle, user requirements created by DSS Lab come with built-in change management tags so that as your business changes and the relative valuation of different kinds of decisions changes, you will be able to see how your information requirements will need to change as well.

Back to DSS Lab Home