We all need a repeatable requirements management methodology to manage the pace of business and technology change every organization is experiencing. We need a methodology that provides insight into project requirements before you spend serious money.
Over the years I’ve developed a very, very simple way to size business/technology projects. Some of you may think it’s too simplistic, but it’s worked pretty well for some pretty complex projects. The methodology is generic enough to be flexible but specific enough to help solve a lot of business/technology alignment problems.
Here’s the methodology in an outline:
1. The Request
1.1 Discretionary/Non-Discretionary Analysis
1.2 Business Linkage
1.3 Technology Linkage
2. Requirements Definition
2.1 Purposeful Requirements
2.2 Functional Requirements
2.3 Non-Functional Requirements
2.4 User Profile
3. Requirements Analysis
3.1 Requirements Prioritization
3.2 Trade-Off Analysis
3.2 Cost Analysis
3.3 Risk Assessment
4. Requirements Model
4.1 Descriptive Model
4.2 Functional Model
4.3 Exploratory Prototype
4.4 Requirements Trace
4.5 The Conceptual Model
5. Requirements Management Process Assumptions
5.1 The Requirements Change Cycle
5.2 Re-Running the Requirements Management Process
6. Requirements Agreement
Let’s look at each of the steps in a little detail.
Request analysis asks the simple question: what’s the project all about? It also asks the analyst and his or her business partner to decide whether the project is “aligned” with the business and technology strategies. The key here is to determine — as early as possible — whether the request is “discretionary” (nice to have) or “non-discretionary” (must have).
In order to analyze and model requirements it’s necessary to define requirements. There are three kinds of requirements: “purposeful,” “functional,” and “non-functional” (or design) requirements.
User profiles are essential to cost-effective design. If users are inexperienced it creates all sorts of problems for the designers and developers of information and software systems. The key is to understand the challenges that the users present to the design and development team before major design and development decisions are made.
Requirements analysis looks at the interrelationships among requirements, the relative importance of requirements, implementation costs, and the risks associated with satisfying each of the purposeful, functional and non-functional requirements. Once requirements have been assessed with reference to costs and risk it’s possible to rank-order them. The drill here requires you to assess whether the requirements are of high, medium or low importance.
Once requirements have been defined and analyzed (in terms of importance, costs and risk), it’s possible to model them. We model because we need to communicate. Good designs emerge from the understanding that results from good communication. We use narratives to communicate, we use simple outlines, we use data flow diagrams, entity relationship diagrams, and hierarchical models. We also use static screen displays and interactive prototypes.
Requirements Change Management & the Requirements Agreement
The change management process is straightforward. All it requires is an agreement among all of the stakeholders that new requirements will be assessed according to their expected impact upon on the existing schedule and budget. If there’s evidence to suggest that the impact will be substantial (more than 5%), then the requirements definition, analysis and modeling process should be re-run.
All we have to do now is write it all down. Yes, and in spite of any visceral objections, we all have to sign an agreement, a kind of baseline contract about what the project’s all about. The fact is that we need a baseline document that describes what the understanding — at a particular point in time — is about what will and will not be done. The agreement itself is part symbolic and part organizational: It commits the stakeholders to an initial course of action and allows the assignment of resources to initial tasks.
A Requirements Management Case Study
Let’s look briefly at some decisions around the deployment of a simulated data warehouse project. The requirements analysis here, however, suggested that the project should be killed! The risks are way too high and the % of effort adds up to 180% of the resources allocated to complete the project!
Functional RequirementsImportance RiskCost 1. Data Base Conversion/IntegrationHH 30% __________________________________________|__________|______|______| _ 2. Data Base CentralizationMM 10% __________________________________________|__________|______|______| 3. Anytime/Anyplace Data MiningHH 30% __________________________________________|__________|______|______| 4. Reporting HM 5% __________________________________________|__________|______|______| Total: 75% Non-Functional RequirementsImportance RiskCost 1.ModifiabilityMM 20% __________________________________________|__________|______|______| 2.UsabilityHH 10% __________________________________________|__________|______|______| 4.Reliability HH 20% __________________________________________|__________|______|______| 5.SurvivabilityHM 10% __________________________________________|__________|______|______| 6.Remote AccessHH 25% __________________________________________|__________|______|______| 7.SecurityHH 20% __________________________________________|__________|______|______| Total: 105% Total Functional & Non-Functional Requirements = 180%
How many of your projects should have been killed?
The worst outcome of the analysis are tons of requirements that are highly important, very risky and very expensive. Too many of these and the project is automatically a death march. On the other hand, it’s great when you identify lots of highly important, low risk, cheap ones, or low importance, high risk, expensive requirements, the ones that can be immediately eliminated from the project.
Obviously not all projects should be killed. But the requirements management methodology described here can help make crazy project assumptions explicit and identify the land mines you’ll have to avoid to survive a major (or minor) business/technology project.
You might try this simple requirements triangulation methodology. It might help you identify projects that simply can’t get done as well as ones that will actually work.
Steve Andriole is the Thomas G. Labrecque Professor of Business at Villanova University, where he conducts applied research in business/technology alignment. He is also the founder and CTO of TechVestCo, a new-economy consortium that focuses on optimizing investments in information technology. Andriole is formerly the senior vice president and CTO of Safeguard Scientifics and the CTO and senior vice president for technology strategy at CIGNA Corp. He can be reached at firstname.lastname@example.org.