THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com January 2000

Requirements gathering (data and process) is a vital part of successful project management and application development—well-known and publicly available research, such as the Standish Group’s Chaos Report, has shown this. Even though there is recognition of the importance of requirements gathering for application development, not enough has been done to explain the underlying need for a requirements gathering process or to develop methods to improve the process. Moreover, it has been common in the Information Technology industry to blame the victim: in other words to blame the customers for not being sufficiently clear about their business requirements. Clients/users can be guided through a process that elicits their business requirements and facilitates accurate application development, but the analyst must be well versed in both understanding the concepts of business requirement gathering AND the process that will best document them.

Budgets and resources are tight, time pressures are constant, and the business is demanding changes, enhancements and new services continually. It should be no surprise that some organizations are still not devoting time to doing data and process analysis, under the misguided perception that short-cutting this activity will shorten the development effort and save costs. However, the end results are quite the opposite. This is the trap that many organizations fell into in the 1970's and early 1980's. Not defining the business data and system requirements at the start of a development project resulted in significant costs in subsequent Software Development Life cycle (SDLC) phases. The reason for this, we now know, is that the analysis activity was simply shifted into other phases of the SDLC, resulting in additional effort and rework. Things are discovered during design, during coding, or during testing that should have been addressed during analysis. This causes lost time, increased effort (because of the ripple effect of the changes required) and increased project cost. Furthermore, costs are increased by changes to requirements during maintenance and enhancement activities, where companies currently spend an average of seventy-seven percent of a department's budget due to missing or incomplete requirements documentation.

The structured information planning methodology that many organizations use has requirements gathering and documentation as its foundation. Data and Process Requirements gathering is part of an analyst’s competency:

• Interviewing subject matter experts and relating needs
• Organizing complex information into understandable subject areas
• "Translating" technical language into business language and vice versa
• Ensuring stakeholder involvement at all levels of involvement
• Drafting clear and concise written documentation for users and technicians
• Working successfully with multidisciplinary teams

If companies don't have time to do it right the first time, when do they have the time to fix it? Devoting so much time to analysis that it interferes with the product delivery isn't the answer either. In this highly competitive world the IT group (clients and consultant partners) must respond better and faster, otherwise our users will look to other providers.

Today, you need a method that captures the users’ requirements, quickly, accurately and completely - one that provides a flexible, yet structured approach to producing a high quality specification, every time. It is essential that companies perform a comprehensive business requirements gathering initiatives to see that application development can be a successful activity.

Specifying Client Business Requirements

- Frequently Asked Questions -

"How do I know we've got all the requirements and haven't missed something?"

"How can I be sure I've got it all, and got it all right?"

No doubt these are some of the major questions we ask ourselves to ensure we're going to develop the highest quality system that meets the demanding needs of our clients. This has been one of the driving objectives of our approach - a systematic application of the best interviewing and modeling practices that gives the analyst the knowledge of what they need to do and the comfort that it has been accurately captured.

"How do you get the users' needs identified quickly and easily?"

Many experts recommend a Requirements Discovery Session with business representatives and an experienced Information Management analyst, using a methodology based in business data understanding. Not a conventional requirements interview, an RDS is focused on the business and should apply proven and easy to understand communication and modeling techniques.

"How do I deal with clients who can't express themselves, keep changing their minds and introduce new requirements?"

An experienced analyst knows what questions to ask using effective communication skills and easy-to-understand modeling techniques. The biggest cause of changing requirements is not asking the right questions in the beginning. A simple, systematic approach leads the analyst and business users to discover all the information requirements, business rules and functionality, which results in a complete and accurate business specification the first time.

"How can we build a system when the users won't invest the time to discuss their needs?"

There's no magic bullet for this issue, but key success factors involve applying an approach that delivers results and is focused on yielding rapid and visible results for business clients. To satisfy the client, we must know what the client wants, and then can show that we have addressed those requirements.

Business Requirement Specification

- Validation Checklist -

To be consistent, the business requirements specification should be accurate, complete and clear. Below is a checklist which represents the attributes of a quality, standard business requirements specification.

Accurate:

• Are the requirements consistent – not contradicting other requirements?
• Are any requirements in conflict with given stated assumptions or constraints (business environment, technical environment, cost, schedule, and resources)?
• Do the requirements support the stated business, system and project objectives?
• Are all activities and operations necessary? Are any identified requirements not required or out of scope?
• Are all data requirements necessary; are any not required or out of scope?

Complete:

• Are the goals and objectives of the system clearly and fully defined?
• Have all events and conditions been handled?
• Have all operations been specified? Are they sufficient to meet the stated system objectives?
• Have all objects and data in the Activity Specification been defined in the model(s)?
• Have all required definitions and rules for objects and data been defined?
• Does the specification satisfy the level of detail required by the design team?
• Have all undefined, unresolved, incomplete specifications been identified for resolution?

Clear:

• Are all requirements free of implementation bias (not restricted to a specific design alternative)?
• Are all requirements precisely and concisely stated?
• Have all operations been stated in terms of their triggering events or conditions, information requirements, processing and outcomes?
• Is the terminology and prose understandable by the business client/users?
• Is there any ambiguity in any of the statements (operations, rules, definitions, etc.)?
• Have all assumptions been clearly stated?

Compliant:

• Has The Sycamore Group’s Information Management Methodology been used?
• Do the deliverables conform to organizational standards, meet organizational process objectives, and follow industry standards?

Information Model – Object Specifications:

• Have all objects been identified?
• Have all objects in the Activity Specification been specified?
• Have all data elements been identified?
• Has all data in the Activity Specification been specified?
• Have all necessary relationships been defined?
• Have all identified data elements been "used"? (at least created and read)
• Have all data items and relationships been correctly and precisely defined?
• Have all data items been accurately attributed to the correct objects (Normalization)?
• Have any Superclasses and Subclasses been identified and specified?
• Have redundant or derived data items and relationships been identified (and/or eliminated)?

Functional Model – Activity Specifications

• Have all required activities been specified?
• Have all operations been correctly and precisely defined?
• Have all outcomes of each operation been specified?
• Have all standard/best practice/or identified life-cycle operations for each object been specified?
• Do all operations identify the event(s) or conditions which trigger them?
• Do all operations identify the operator (system or user)?
• Do all operations use strong, unambiguous action verbs?
• Are all specifications clear and unambiguous?
• Is the data used in the operation clearly understood?
• Do required operations use rules, formulas or conditions to qualify or define the processing of the operation?
• Do all operations specify or clearly imply an outcome?
• Has the Context Diagram been updated?
• Have all interfaces and activities in the Context Diagram been specified?

In the final analysis, using the methodological approach to business requirements gathering will enable an organization to collect, segregate, prioritize, analyze and document all the relevant informational and process needs for the application under design. This understanding of the business needs for data and process will result in useable, robust and sustainable systems that give an organization a competitive edge.