Incomplete, vague or inaccurate requirements are often the cause of failed software projects. Outsourcing can compound this problem if the project scope isn’t carefully managed. However, the right tools and processes can dramatically improve your chances of success.
Requirements form the basis of any project, whether in the form of specifications, use cases, statements of need, or just “wish lists” from the marketing department. The requirements define the problem to be solved and the solution to be provided. If the initial problem isn’t analyzed carefully so that it can be described unambiguously, then you may find that the delivered solution doesn’t actually perform the required task.
User Requirements
So, the first phase of requirements analysis — that of the user (or stakeholder) requirements — is almost invariably performed in-house. This phase defines the goals that the system must achieve. For example, “The customer shall be able to determine their account balance within two minutes of initiating contact with the online banking system.” The “user” in user requirements isn’t necessarily a person; it may be another system, whether software or hardware.
The second phase of requirements analysis — that of system requirements or system specification — involves analysis of the user requirements and proposal of a solution. In other words, the system requirements specify, from the user’s point of view, how the user requirements will be satisfied. This need not require a detailed design, but should describe how the user of the system can achieve their goal. For example, “The first page displayed to the customer after login shall include all account balances.”
Producing system requirements from user requirements often involves a process of clarification of the user requirements together with modeling of prospective solutions. For a project that is to be outsourced, this process could be part of the negotiations with the service provider, but will still require a great deal of input and review by your in-house team. Misunderstandings due to the outsourcing partner’s lack of experience in the problem domain are common at this stage.
A better solution would be to have the in-house team develop the system specification. If the requirements are well-written, then the scope for misunderstanding can be reduced, though it’s inevitable that queries will arise throughout the project. You’ll need to have someone with technical knowledge available to field these questions, preferably someone who was involved in the analysis that led to the system requirements. For a fairly small-scale software project lasting six months and employing an offshore team of about 10 people, we found dealing with technical queries required about 20% of an in-house senior engineer’s time.
The requirements for an outsourced project should also include any implicit requirements, such as conformance to company standard user interface standards. Such standards may be informal when development is performed by a single team; they must be made explicit for an external partner.
Managing System Requirements
The development of the system specification is crucial. Fortunately, a few simple rules can help ensure that the system requirements are complete and correct.
First, each system requirement should be associated with some user requirement. Often any uncertainty about the meaning of a system requirement can be clarified by referring to the original problem the system requirement was intended to solve. You may discover that you need some clarification of the user requirements at this stage.
Second, each requirement should be testable. Naturally, you should require your service provider to perform testing, but you should also develop your own acceptance tests. Your tests should be linked to the system requirements they verify, so that you can ensure the testing covers all requirements. Development of these tests should begin as soon as the system requirements have been approved, although details may have to wait until the design stage. The tests you develop can be a valuable tool for clarifying your intentions about the use of the system.
Finally, each requirement should be feasible. Development of the system requirements will generally include modeling of potential solutions, whether in a formal UML tool or on a whiteboard in the engineers’ lab. If possible, these models should be shared with your outsourcing partner, even if they don’t turn out to be the basis for the eventual design. They will provide a common framework for the discussion of the system’s behavior.
The final system requirements should be reviewed by as many people as possible in your marketing, engineering and test departments. Reviewers should check that the requirements are clear, testable and feasible; that they satisfy the user requirements; and that they’re coherent when taken as a whole.
Plan for Change
No matter how much effort you put into the user and system requirements, it’s almost inevitable that changes will be necessary after development has begun. The process of design development may reveal subtle inconsistencies in the user or system requirements, or there may be good technical reasons why a system requirement can’t be satisfied. On the other side, acceptance test development may reveal an omission in the specification, or marketing requirements may change because of external factors, such as the release of a new product or platform.
However, if you’re prepared for such changes, they can be managed to cause the minimum disruption to your schedule. The key to this preparation is ensuring you can trace the impact of any given change.
Before development begins, you should baseline the user and system requirements so that you can easily identify any introduced changes. You should also have completed the process of creating links between the system and user requirements; as acceptance test development proceeds, these should be linked to the system requirements as well.
You can even take this one step further. If you include design documents in your deliverables, you can link elements of the design to the system requirements they’re intended to implement. This is particularly valuable for GUI design, as you should be able to check easily which system requirements aren’t covered.
When changes do occur, you can judge the impact of the change by following the links. For example, if a user requirement changes, you can check to see what changes are necessary to the associated system requirements, tests and design. Similarly, if the design changes, you can verify that the new design still satisfies the original requirement or determine if the system requirement also needs to be modified.
With careful system specification, regular feedback of design information and ongoing management of changes, you can ensure that the results of your outsourcing project will meet your needs.
