Technology Point
Having identified a business need for new software, IT managers must make the decision to either build a custom application or purchase a commercial-off-the-shelf (COTS) product. Regardless of the choice, IT must make sure business needs are adequately understood so that it can deliver a suitable solution. In some cases, the build versus buy choice can depend upon what the business requirements are (e.g. whether customization is necessary or cost effective).
Software projects with any degree of complexity need a formal requirements gathering process to ensure that the requirements are accurately identified, reviewed, documented (i.e. textual documentation, prototypes, and models), and approved. Failure to properly execute the requirements gathering phase can be costly. Studies have repeatedly shown that poor requirements gathering is a leading cause of project failure. Up to 50% of project rework is attributable to problems with requirements, and of projects that fail, 70% fail due to poor requirements (source: IAG Consulting and Info-Tech Research Group’s Business Analysis Benchmark).
Avoid the pitfalls of poor requirements with a solid understanding of the requirements gathering process and knowledge of the key factors that impact it.
What It Is & How It Works
Requirements Explained
The International Institute of Business Analysis (IIBA) provides a general definition of requirements in its Business Analysis Body of Knowledge (BABOK 2.0). According to the BABOK 2.0, a requirement is any of the following:
1.A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2.A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3.A documented representation of a condition or capability as in (1) or (2).
In the context of application development or procurement, a requirement can be more narrowly defined as a capability that a software application must possess in order to address a specific business need or objective. The total set of capabilities that a given software solution must have is called the “solution scope.”
There are several different levels at which a requirement can be defined for a given software solution. The IIBA’s definitions of requirements - adapted for a software context - are listed below:
•Business requirements are the high level problems – the goals, objectives, and needs of the enterprise – that are to be solved by the proposed application.
•Stakeholder requirements are the specific needs of a particular stakeholder or group of stakeholders. They describe the needs a given stakeholder has with respect to a potential software solution. Stakeholder requirements connect business requirements with the various types of solution requirements.
•Solution requirements describe the specific characteristics a software application must have in order to meet both the business requirements and the stakeholder requirements (see Figure 1).
Solution requirements are further divided into the following categories:
•Functional requirements specify how the solution will operate (its behavior) and the kinds of information that it will manage. They describe the capabilities of the system and explain how it will perform specific operations.
•Non-functional requirements are conditions that do not relate directly to the behavior or functionality of the solution, but rather describe environmental conditions under which the system must remain effective (e.g. technical constraints, capacity and performance requirements) or qualitative properties the system must have (e.g. user experience requirements).
•Implementation requirements describe the capabilities a software application must have in order to facilitate the transition from the current state of the enterprise to the desired future state, but that will not be needed once the transition is complete (e.g. interaction with other systems).
Requirements need to be clearly described and documented in the project’s goals and objectives. Doing so will enable the project team to significantly narrow the range of available software choices in the case of procurement. With custom development, clear requirements enable the design, development, testing, and deployment of the software solution to a business problem. Requirements drive every subsequent phase of the software development lifecycle.
Source: http://www.infotech.com