Requirements Analysis and Management

Requirements-gathering is the ‘hot potato’ of software development. Whose job is it? Business thinks IT should be defining requirements; IT replies that they can’t be expected to know what the business wants. Whose problem is it? Everyone’s. Without good requirements, the business doesn’t get what it envisioned and IT gets a black eye.

What’s to be done? Clearly both the business side and the technical side need to be involved. You can link the two by bringing in “someone in the middle” to facilitate communication and to document requirements in a way that both sides understand. That’s where DEA comes in. We call ourselves requirements architects because we believe we play a middle role and provide a neutral perspective just like an architect involved in a building project. We ensure that business need drives the solution; at the same time we have the technical expertise that allows us to represent the requirements throughout development.

We can work with you wherever you need us:

• At an enterprise level, where you need requirements to identify what projects are key to tackle and in what order
• At a business area level, where we can analyze a business process to identify requirements for improvement
• At a tactical level, where we can help with requirements for replacing a legacy system, or for automation of a business process with new systems or packages

As requirements experts with over twelve years in business and 20 years of experience, we’ve learned that certain principles are crucial to successful requirements.

Business Need Should Drive Requirements
Business need must be made explicit and then used to drive project goals. Building requirements projects around a business case that outlines the benefit that will be achieved, means that requirements efforts will be guided by real business need and business benefit, rather than by the desire for bells and whistles or a new technical toy.

Don’t Let Software Vendors Build Your Requirements
Separate the responsibility for defining requirements and performing testing from the responsibility for design and development. Simply put, that means don’t let a software package vendor build the requirements! The focus of a sofware vendor must be on the software itself – its functionality, its extensibility, and its support needs. That means the vendor may be thinking not about helping you improve your business process, but rather about how to change your business process to take advantage of their tool. Don’t base your requirements on a particular package’s available functionality, base them on your business needs.

Requirements Must Be Managed
The approach you take to gathering, reviewing, tracking, and managing change to requirements is crucial. The Standish Report documents the following as the top three factors causing project failures:

• Lack of user input
• Incomplete requirements
• Changing requirements

Gathering and specifying excellent requirements is, of course, key. But change is inevitable and you will need an approach to managing change to requirements throughout the life of a project if you are to reach a successful conclusion. Managing change means three things: documenting an approach to making change (who will have rights to request or make changes and how will changes be carried out and communicated); documenting how change history will be tracked; and providing the capability to see where a requirement has come from (what business objective it addresses) as well as where a requirement is going (how it is designed, built, tested and implemented).

DEA includes a structured and comprehensive Requirements Management Strategy phase in its LINKProcess. We also have built requirements change history and requirements traceability into our RequirementsLINK tool as integral functions.

Requirements Should Be Model-Based
Just as in building a house, a good software requirements process must have a way to help the business owners discover and document what they want in their own terms. And a good software requirements process must have a way to communicate unambiguous requirements to the developers (the plumber, the electrician).

What can link the two worlds of IT and business? At DEA, we believe the answer is models. Models help you ‘see’ what the finished product will be like. They provide a way for users to verify the correctness of their needs, because they can “walk” the process by means of the diagrams. The requirements models then drive the rest of the project. They become the basis for user interface designs, for application architecture models, for design specs, for system interface specs, and for acceptance tests.

Requirements Can Drive Testing
In the early days of use cases, advocates suggested that one advantage was how easily use cases could become test cases/test scripts. But there was little guidance on how, exactly, this translation should take place. Here’s one successful strategy. If you follow these steps, your user acceptance testing will be based on your requirements (what the user wanted), not on the code (what the designer built).

Step 1: Begin your requirements analysis by documenting use cases. Detail each use case behavior with a “use case flow” model that illustrates possible scenarios, decisions, and user interaction.

Step 2: Use the use case flow model to generate user test scenarios, script-like documents that capture what the user does, what the system does, what data is used, and what rules must be followed. If you use a repository-based modeling tool to build use cases, you can create a macro to generate these documents directly from the models. While these user test scenarios are close to test scripts, they are not yet complete.

Step 3: Determine test cases. Use the scenarios and the business rules to come up with enough test cases to thoroughly test the system behavior.

Step 4: Write test scripts. Each test case needs one or more test scripts. The user test scenarios from Step 2 are the starting point. Then you fill in detail, for example, exactly what name do I enter? Or what account number do I use? You also document the expected results, so that your testers know what to look for.

Step 5: Put the test scripts on the web and allow testers (which in this case should be end users) to enter their comments online into a database that can then be reported against.

What does a typical requirements project look like? The table below shows our overall approach.