It is the IT professional's misfortune that he or she has to try to convey complex IT developments to a board that has little understanding of technology.
Meanwhile, it is the board's misfortune that for so long IT professionals have been unable to clearly state their purpose, to the organisation or to produce the results to make the rest of the business wake up to the importance of what effective IT can bring to a business.
However, it seems that things are starting to change. The IT sector is beginning to see the need to improve its performance and success rate, whilst business is beginning to understand and appreciate the potential benefits of an integrated, well-directed IT department.
All of a sudden, business-IT alignment has taken on a new importance. It is now being discussed in boardrooms throughout the world as executives realize that IT – and particularly software – not only runs a business but can be its biggest competitive weapon.
When it comes to developing and maintaining high-value software, there are a number of processes that lend themselves to business-IT alignment, none more so than the process of defining and managing business and technical requirements for both new and existing applications.
These requirements impact every single step of the application life cycle, from design and coding to testing and deployment. And because requirements have such an impact downstream, it's no surprise that studies cite inaccurate, incomplete and mismanaged requirements as the primary reason for project failure according to the Standish Group CHAOS report 2004.
An effective requirements engineering process consists of two major domains - definition and management. It is the definition process that aligns stakeholders with shared goals and expectations, and what helps bridge the significant communication gap between IT and the business.
The management process enables an organisation to respond quickly to change and to ensure the resulting application effectively meets customer needs.
So how can IT teams better understand the business requirements in order to deliver well-directed, valuable software?
Requirements elicitation
Understanding user or system requirements is more about discovery than about documentation. In order to identify an accurate and complete set of requirements, it is imperative to first define the ultimate purpose and form of the new system or application.
What is the scope of the project and how will it integrate into the business?
Every software project should also identify the key stakeholders at the earliest possible stage to ensure that the right people can make important and timely decisions. The customer perspective is also required in all aspects of the process.
Indeed, teams must determine who will serve as the literal voice of the customer for each type of user who might touch the system or application. These representatives are called champions. When engaging champions, it’s important to agree on the level of involvement.
However, once champions are in place, there are a range of methods that can be used for requirements elicitation depending on the extent of stakeholder involvement and how much access one has to those stakeholders.
Workshops to explore scenarios work well when user representatives are locally available, whereas questionnaires and surveys might be necessary if there are many geographically distributed stakeholders.
Discussions that focus on how users interact with a product or system generally yield the best results. Users find it more natural to describe their business tasks and usage goals than to define all of the functionality they expect to see in a product.
Use cases, scenarios and user stories are related terms that are used frequently to describe a system’s user requirements.
Once requirements are discovered, the team must verify that these requirements are complete and achievable. This involves estimating the time and resources needed to achieve the requirements, and if necessary, prioritizing what can be done.
Requirements are often full of ambiguities, redundancies and gaps. Therefore, it is necessary to present requirements in multiple ways, giving readers a richer, more holistic understanding of them.
Analysis models present requirements information visually, in graphical diagrams. They allow reviewers to immediately spot missing requirements by examining diagrams.
Every organisation has limited resources and time. Therefore, every team should determine which of its requirements are most important and most urgent. This allows teams to implement the right sets of user functionality in the right sequence.
Requirements specification
This critical step in the process fills out the details for each requirement and helps to clarify ambiguities that can result in rework, schedule delays, budget overruns or outright project failure.
Requirements, especially those written only in natural language and not represented visually, are fraught with ambiguity. Negative requirements, use of vague and subjective terms, complex logic, omissions, synonyms and adverbs lead to multiple interpretations by different readers.
By storing requirements in a commercial requirements management tool teams can overcome many of the limitations imposed by textual documents. Requirements management tools make it easy to store additional information-attributes-about different classes of requirements information.
They facilitate tracking requirements status and provide a mechanism for retaining requirements that have been proposed, rejected or approved, and later deleted from a baseline. The tools also make it easier for distributed teams to collaborate.
Once requirements are defined, they must be validated with the original stakeholders before development begins. Peer reviews indicate how well others understand the requirements and ensure accuracy, completeness, and that the optimal level of detail is in place for developers to deliver software that truly meets business needs.
Requirements management
Finally, after the requirements are elicited, analysed, specified and validated, they are ready to be executed in the various phases of the development process.
As requirements evolve during the course of a project, it is important to track the different versions of requirements specification documents. Proposed modifications to requirements should follow an established change control process to provide consistency in the way requirement changes are proposed, evaluated, approved or rejected.
Teams should track and report on the status of individual functional requirements so that they can easily assess the health of the project and avoid unnecessary status meetings.
Good requirements practices yield positive results
Besides the obvious cost benefits, improving requirements approaches leads to other valuable, but less tangible, outcomes. Experiencing fewer miscommunications on a software project reduces the overall level of complexity in the IT organisation.
Less chaos lowers unpaid overtime, increases team morale, boosts employee retention and improves the team's chances of delivering on time. Best of all, these benefits lead to higher satisfaction with both internal and external customers.
