Requirements Elicitation & Documentation

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

With over 17 years of business analysis 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. DEA’s LINKProcess has integrated these testing considerations into its overall strategy through the use of detailed “use case flow” models. Coupled with a repository based modeling tool, these models incorporate user interactions, decisions, data elements, screen mockups and requirements to illustrate possible test scenarios that can serve as the backbone for future test cases/test scripts. By utilizing this process, user acceptance testing will be based on the requirements (what the user wanted), not the code (what the designer built).