Requirements management
Contents |
Overview
According to The Office of Government Commerce, UK, defines requirements are “capabilities and objectives to which any product or service must conform and are common to all development and other engineering activities” and requirements management is “the process of eliciting, documenting, organising, and tracking requirements and communicating this information across the various stakeholders and the project team”.
From this, requirements management can be described as a strategy that has to be used by any organisation in order to make sure that the expectations coming from its customers, internal and external stakeholders are properly identified and managed. The purpose of requirements engineering is to track, identify, control and communicate these requirements, and to manage any changes to these requirements, at any time in the project process. Requirements management is performed during all the project life-cycle, but it is also one of the major sub-processes of the pre-project planning, since it contributes to the project performances in terms of costs, schedule and quality performance[1]. Indeed, requirements are defined as all the goals to be achieved in order to make a product or a system complete and successful. Requirements management thus helps defining a project and providing a framework, allowing the project to be tracked and the objectives to be completed, in order to make the project successful. Because requirements are open to change, project managers have to be prepared to any possible change in the project scope or in the requirements within the project’s process, and to manage these changes.
A good requirements management is the key to projects success and better business results. A poor requirements management often lead to project failure [2] : delayed projects, budget overruns, or products that don't come out as designed.
Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools.
Requirements management: how to make a project successful?
Definition of project success
The success of a project can be described in different ways, but the common criteria is the ability of a project manager to deliver a project in respecting time and budget constraints as well as respecting the customer's expectations. The system or product that have been promised must be the one to be delivered; this is only possible when all the requirements are fulfilled. Project managers need these requirements management in order to reduce uncertainty, ambiguity and mis-perception when managing a particular project.
Aaron et al.[3] define the success of a project in terms of the following criteria: - The project efficiency: the achievement of the specified project goals, such as time, budget, performance and other requirements, - The impact on the customer: the achievement of functional an technical performances, the solving of the customer's problem and the fulfilling of its needs, resulting in customer's satisfaction and loyalty - The business success, i.e. the impact and benefits on the performing organisation, such as profits, market share and growth, - The ability to prepare the organisation to future challenges, in terms of long-term benefits.
Obviously, these dimensions do not have the same role for different types of projects. Regarding the customer's requirements, the customers expect different things from small-projects - a standard solution - than for greater projects - a unique solution with high capabilities and effectiveness. The highest complexity comes from bigger and more complex projects, which regard advanced needs for which maybe no previous solution exists. These projects involve high risks, but they meet success when they finally achieve to completely satisfy the customer, i.e. find a solution that could not be found before.
Meeting the customer's expectations is key to any project success, since it means meeting performance, functional and technical requirements. Besides, satisfying the customer allows to meet other success criteria, especially the impact on the organisation and long-terms benefits; a satisfied customer will come back for further needs, and participate in promoting the organisation.
Poor requirement management as a cause for project failure
A good requirements management is a requisite for a successful complex project. Indeed, researches conducted on failed projects show that failure to manage requirements is one of the main sources of project failure. Reasons for project failure regarding requirements are the ones following[2]:
- A lack of user input,
- Incomplete requirements,
- Changing requirements,
- Unrealistic expectations,
- Unclear objectives.
These reasons are signs of a poor requirement management and any problem affecting requirements, such as incomplete or ambiguous requirements, must be identified in order to reduce the project risk[4].
Application context
Requirements management is a practice which is relevant in any kind of projects, especially in system engineering, software engineering and product development projects, construction projects…
System engineering processes[5]
As satisfying customer’s needs is one of the main purposes of system engineering, requirements are part of every system engineering process. They are directly related to the customer’s needs and the objectives for the system being designed; in this way, they are linked to the performance of the system, since they are describing how well the system is supposed to work in its environment. Within any system engineering process, the elicited requirements are being analysed in order to be transformed into designs, taking into account existing constraints.
The customer’s needs, constraints and requirements are the main inputs of a system engineering process. The first step of the process is to analyse them in order to determine functional and performance requirements.
Product development projects
Requirements management is big issue when it comes to product development processes. Product development projects are becoming more and more complex, especially because of the increasing variety of demands from customers. As a matter of fact, a new designed product needs to fulfil the customer’s expectations, because the person who buys the product is the most important person in determining the commercial success of a product; in this way, the customer’s satisfaction is one of the major criteria in the success of a new designed product. This is why the process of product development is a user-centred process: the priority is given to the voice of the customer. Identifying the customer’s requirements allows defining the product’s attributes and specifying the performance required by the designed product.
A way to keep track of the customer’s requirements in new product development is Quality Function Development, which is a tool used for defining the characteristics of a product as targets to be achieved for the engineering characteristics of the product in a way that customer’s requirements are satisfied. Requirement management in new product development also requires to focus on the possible changes in the customer’s requirements and then in the project scope. As there are always more groups now involved in the product development tasks, a good requirements definition and management allows a clearer and more organised overview of the overall project which also facilitate group-decision making, by providing a better and continuous communication between the involved stakeholders.
Construction projects
One of the earliest phases of any construction project is the elicitation, analysis, specification and validation of the client’s requirements. Client's requirements constitute the main source of information for any construction project[6]. The proposed or constructed facility must satisfy the client's wishes.
The complexity in construction projects is to satisfy both the paying clients and the using clients. Moreover, in construction projects, other requirements have to be taken into account and cannot be neglected, such as site requirements, environmental requirements or regulation requirements generated by construction codes. Client's requirements and construction requirements interact and can concurrent each others, which results in more constraints to be identified.
Because construction projects are usually experiencing delays and budget overruns, requirements have to be tracked in a satisfactory way. Moreover, managing requirements all along the construction project contributes to reduction or elimination of waste in design and construction[7].
Main steps of requirements management
Requirement elicitation
The requirements for a project can come from different possible sources, for example[4]:
- The stakeholders i.e. all the interested parties. This is the first source to be considered, as the system or product must meet the stakeholders’ desires and needs in the first place. Stakeholders have to be properly identified and their points of view have to be fully understood.
- The environment in which the system will exist and be performed and the system’s potential impact on it.
- The possible interfaces with other existing systems and the associated requirements.
- The requirements specific to the implementation of the system
The complete identification of the sources of requirement from the very beginning of the project is a way to avoid any unknown requirement to emerge later in the project process, which will have consequences in terms of time and money.
Requirements elicitation consists in understanding the needs of the stakeholders or any source of requirements and collecting them for a future analysis[8]. In product development, it consists in determining all the features that need to be included in the product. The requirements can be elicited by observing, interviewing or questioning any known source of requirements.
Some conditions have to be fulfilled in eliciting the requirements. They have to be constantly reviewed in order to detect any incomplete or ambiguous requirement or any conflict between requirements. Requirements must be understandable, achievable, verifiable, and unambiguous[5].
Requirements documentation
Requirements have to be properly stated and documented in order to be fully understood by any entity involved in the project process, and in order to be managed efficiently throughout all the phases of the project. Indeed, requirement management is all about the ability, not only to elicit requirement, but also to write them in a way that they are readable, understandable and traceable by many, in order to be able to follow their evolution throughout time[9]. The elicited requirements need to be kept fully accessible[7] at any time within the project life-cycle; indeed, the different teams and stakeholders, have interests in different requirements and during different phases of the project life-cycle.
Requirements analysis
Every project meets different kinds of requirements; requirements analysis consists in determining how to categorise each requirement. A common categorisation is listed below[1][5]:
- The business requirements are high-level requirements describing what has to be realised to produce value out of a new product or system.
- The customer’s requirements define the exact expectations of the system or product.
- The functional requirements describe the functions required from the system or product, i.e. what it must do or provide, what exactly needs to be done. These requirements allow a very detailed description of the system or product.
- The performance requirements describe the expected performance of the system in fulfilling the previous described functions, i.e. how well the functions have to be fulfilled.
- The quality requirements cover non-functional attributes such as safety, maintainability, operability or environmental requirements.
- The process requirements describe the process to be followed and the constraints to be conformed to while realising the project, for example how the system has to be executed or delivered.
- The programme requirements cover all the deadlines in the project process, especially when the system or product has to be delivered.
This list is non-exhaustive but provides a good idea of which kinds of requirements can be met in the project life-cycle. Business requirements are usually made for the project managers and the board of the organisation to read and understand them, whereas the functional requirements are more intended for project managers but also developers and testers. The functional requirements respond to the business requirements.
Requirements analysis should result in a clear understanding of the functions of the system or product (what does it have to do?), its performance (how well do the functions have to be performed?) and its interfaces (in which environment will the system perform?). The analysis particularly highlights the functional, physical and operational views of the design: the operational view relates how the product will serve its user; the functional view focuses on what the product has to do; the physical view describes how the product is constructed. In the end, requirements analysis allows having a successful design definition[5].
All different requirements need to be ranked, which means that there is a need to know which the most important requirements are, and which of these requirements have to be prioritised[10] . Requirements can be scaled with regard to their importance for the customer but also to cost they involve. Several prioritisation methods can be used that will not be detailed here.
Requirements change management
Requirements definition is one of the first steps of a project process, because it allows the project to be properly defined by setting all the goals to be reached. However, requirements can emerge all along the life-cycle of the project process. In fact, it is not uncommon that the requirements change throughout the engineering process, and some reasons for that can be for instance:
- A change in the needs of the stakeholders, for example because of a lack of understanding
- Identification of a conflict between the stated requirements
- A requirement appears to be unachievable
- A change in the business environment
- A change in the laws or regulations
- The first considered solution appears to be not realisable
- A change in the trade-offs
- In a construction project, the need to adapt a new facility to other uses than the ones it was originally designed
These changes are the reason why requirements management is needed throughout the life-cycle and not only in the first phases. Requirements management provides visibility, tracking and traceability of the requirements, which are crucial elements in case of such changing circumstances. The inability to manage these changing requirements is often considered as a cause for project failure, impacting both cost and duration. Traceability is one of the main ways to identify, understand and support a change and its impact.
Of course, managing changes appears to be the most difficult task in requirements management.
References
- ↑ 1.0 1.1 Li-Ren Yang, Jieh-Haur Chen, Xing-Liang Wang, Effect of requirements definition and management on performance outcomes: roles of interpersonal conflict, product advantage and project type, International Journal of Project Management 33 (2015) 67–80, 2014
- ↑ 2.0 2.1 Standish Group Report Chaos, www.standishgroup.com (available free from many educational sources on the web)
- ↑ Aaron, S.J., Don, D., Ofer, L., Alan, M.C., 2001. Project success: amultidimensional strategic concept. Long Range Plann. 34 (6), 699–725.
- ↑ 4.0 4.1 Andrew Bourne, System Requirements Management, Tube Lines Ltd., UK
- ↑ 5.0 5.1 5.2 5.3 Systems Engineering Fundamentals, Department of Defense, Systems Management College, Supplementary text prepared by the defense acquisition university press, Fort Belvoir, Virginia 22060-5565, January 2001
- ↑ J . M. KAMARA, C. J. ANUMBA & N. F. O. EVBUOMWAN, Establishing and processing client requirements - a key aspect of concurrent engineering in construction, Engineering, Construction and Architectural Management 2000 7|1, 15–28
- ↑ 7.0 7.1 JALLOW, A.K. ... 2008. Lifecycle approach to requirements information management in construction projects: state-of-the-art and future trends. IN: Dainty, A.R.J. (ed.). Proceedings of 24th Annual Conference of Association of Researchers in Construction Management ARCOM, September 1-3, 2008, University of Glamorgan, Cardiff, Wales. Vol.2, pp 769-778.
- ↑ Alan M. Davis, Ed Yourdon, Ann S. Zweig, Requirements Management Made Easy, Omni-Vista, Inc.
- ↑ Bashar Nuseibeh, Steve Easterbrook, Requirements Engineering: A Roadmap
- ↑ Yvonne Bijan, Junfang Yu, Jerrell Stracener, Timothy Woods, Systems Requirements Engineering—State of the Methodology, Wiley Online Library (wileyonlinelibrary.com) DOI 10.1002/sys.21227, 2012
