DTU ProjectLab - User contributions [en-gb]

Talk:Requirements management

2014-12-01T17:31:56Z

Eniram: /* NobodyKnows Peer Review */

'''My answer to the reviews is written in bold'''

= NobodyKnows Peer Review=
I have gone through the wiki article and the review will be based from a chapter overview and finally an overall review. There are only comments if a section is shown below.

== Overview ==
* I like the starting definition, but it would be nice with a relevant reference - see below.
** "According to The Office of Government Commerce in United Kingdom, 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''”."
*** '''I thought that writing where the quote came from was sufficient, but I have now updated the source
'''
* I would not use acronyms, when writing a "scientific wiki" article
** 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.
*** '''You are right, it was a inattention mistake that I now have corrected.'''

* You state that "Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools."
** This is not really mentioned in depth throughout the article, but sound very interesting.
*** '''Some companies use only tools like excel or word (basically lists) but for complex projects it seems that there are kinds of software for managing requirements. I did not see the point in explaining them in the article because there are a lot (there is not only ''one'' good way to manage requirements) and they are produced by private companies.'''

=== Overall impression of the ''Overview chapter'' ===
* It is a real nice overview of Requirements Management and I want to keep reading!
** '''Thank you!'''

== Definition of project success ==
* Please add a reference for this. A strong statement needs a reference.
** "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."
*** '''Actually, this is my own point of view on how to define the success of a project. Of course, I was also helped by the readings I have done, but I cannot add one reference for this statement...'''

=== Overall impression of the ''project success'' ===
* It would be very nice if a definition of "customers" regarding projects could be made and maybe a few examples.
** '''I think it was obvious but it seems that it is not, so I added explanation.'''
* Please consider if it is only the customers expectations that needs to be satisfied - if yes - please state why?
** '''I do not understand what you mean here? I detailed 4 criteria to define project success, customer's satisfaction is one of them but there are still 3 other, but they are detailed. I meant here that the customers' requirements are one main aspect to consider in a project in order for it to be successful.'''

== Application context ==
* An idea would be to make a reference to a wiki article regarding "System Engineering"
** '''This is true, a link to the article comparing systems engineering and project management is absolutely justified here and can be a good complement to my article. So I have now added the link!'''

== System engineering processes ==
* It feels like the section just ends, without a "wrap-up".

== Product development projects ==
* Please assign reference
** Product development projects are becoming more and more complex, especially because of the increasing variety of demands from customers

* Please assign reference
** 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.

* Good informative chapter!
** '''I have now added references'''

== Construction projects ==
* A reference is needed for this.
** Because construction projects are usually experiencing delays and budget overruns, requirements have to be tracked in a satisfactory way

=== Overall impression of the ''Application context'' ===
* Very good idea to present different aspects, where Requirement management is relevant!
* Overall a very good chapter, but there is a lack of references.

== Requirements elicitation==
* Very good chapter, easy to understand.
== Requirements analysis ==
* Very well written section, but it would be very nice with a discussion regarding the Strength and weaknesses etc..

== Requirements change management ==
* Very interesting aspect to consider!
* There are no references assigned to this section.
** '''I have now assigned my references'''

=Overall feedback=
* Please read the article for grammatical errors (not many, but a few).
* I would properly introduce the section "Main steps of requirements management" earlier so when reading the different areas, where this approach is relevant the reader will already have an idea of what it is.
** '''You are right, it makes more sense to explain the steps first, and add the application chapter as examples in the end.'''
* Please be more critical throughout the article
** state strength, weaknesses and controversial points.
*** '''I wrote my article as an 'introduction and overview' article. It is open to discussion but I do not think it is the purpose of my article.'''
* An example for how to apply requirements management would be very nice, so the reader could get an idea of how to implement this in his/her project.
* An overall comment is that there a missing a lot of references, when doing this kind of article.
* Please be aware of copy&paste.
* Please attach "categories".
** '''Two categories were already attached.'''

= MartinKruck peer review =

= Formal aspect =

'''References'''
As mentioned by NobodyKnows, you should remember to use references.

'''Language'''
When rereading your article be mindful of your english, especially when using the suffix -s
e.g.: "As a matter of fact, a new designed product need (not:needs) to fulfil the customer’s expectations"
* '''why not needs? I do not understand this rule...'''

As mentioned by NobodyKnows, you should not use acronyms (don't, shouldn't). But I am sure that was just a slip up, since it only happened once ;-)
* '''Now corrected!'''

Also remember that [:] forces capital on the following letter. You have a title saying: "Requirements management: how to make a project successful?"
* '''I did not know this rule (in French, colons call for lowercase!). I think I corrected it everywhere.'''
Further more; this is not a question. Since this is the only title with a colon [:] it looks weird. Consider rewriting the other titles to the same format or rephrase the title to something like: How to make a successful using requirements management
* '''You are right, I did not really know how to turn this title. I think I have now found a better one.'''
Other than those I only stumbled a few times. 8/10 on your english.
* '''Thank you! That's good to know, I was kind of worried about this :\'''

'''Figures'''
I feel that most of your partitions could use some figures to illustrate their points, especially chapter 3 and 4, where you discuss some very valid points, which are also though to read since they are very complex.
* '''You are absolutely right. I know I should put figures and I would have liked to add some but unfortunately I could not find very accurate ones and I lacked time, so I wanted to focus on the text...'''

= Content =

Chapter 1 gives a great definition of the subject, but does not give a great summary of what is to come.

Chapter 2 is very well written and could only benefit from a few useful figures.

Chapter 3 loses some of its focus. I think that starting each topic with a '''short''' presentation on what each project is about and what/how requirements management is to be used, would help this part.

Chapter 4 is a bit confusing. I think that you should look further into your use of layout and/or use appropriate figures.

BTW you mention stakeholders. This subject is covered [[Mapping Stakeholders]] code: <nowiki>[[Mapping Stakeholders]]</nowiki>
* '''There are a lot of wiki articles about stakeholders! But I will try to find one to link here, because it is relevant.'''

Otherwise I think that the article is great and gave me some new knowledge. Keep up the good work!
* '''Thank you very much for your review! I also learnt a lot when doing this article ;)'''

Talk:Requirements management

2014-12-01T13:21:55Z

Eniram: /* Content */

= NobodyKnows Peer Review=
I have gone through the wiki article and the review will be based from a chapter overview and finally an overall review. There are only comments if a section is shown below.

'''I will reply to your feedback in bold.'''

== Overview ==
* I like the starting definition, but it would be nice with a relevant reference - see below.
** "According to The Office of Government Commerce in United Kingdom, 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''”."
*** '''I thought that writing where the quote came from was sufficient, but I have now updated the source
'''
* I would not use acronyms, when writing a "scientific wiki" article
** 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.
*** '''You are right, it was a inattention mistake that I now have corrected.'''

* You state that "Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools."
** This is not really mentioned in depth throughout the article, but sound very interesting.
*** '''Some companies use only tools like excel or word (basically lists) but for complex projects it seems that there are kinds of software for managing requirements. I did not see the point in explaining them in the article because there are a lot (there is not only ''one'' good way to manage requirements) and they are produced by private companies.'''

=== Overall impression of the ''Overview chapter'' ===
* It is a real nice overview of Requirements Management and I want to keep reading!
** '''Thank you!'''

== Definition of project success ==
* Please add a reference for this. A strong statement needs a reference.
** "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."
*** '''Actually, this is my own point of view on how to define the success of a project. Of course, I was also helped by the readings I have done, but I cannot add one reference for this statement...'''

=== Overall impression of the ''project success'' ===
* It would be very nice if a definition of "customers" regarding projects could be made and maybe a few examples.
** '''I think it was obvious but it seems that it is not, so I added explanation.'''
* Please consider if it is only the customers expectations that needs to be satisfied - if yes - please state why?
** '''I do not understand what you mean here? I detailed 4 criteria to define project success, customer's satisfaction is one of them but there are still 3 other, but they are detailed. I meant here that the customers' requirements are one main aspect to consider in a project in order for it to be successful.'''

== Application context ==
* An idea would be to make a reference to a wiki article regarding "System Engineering"
** '''This is true, a link to the article comparing systems engineering and project management is absolutely justified here and can be a good complement to my article. So I have now added the link!'''

== System engineering processes ==
* It feels like the section just ends, without a "wrap-up".

== Product development projects ==
* Please assign reference
** Product development projects are becoming more and more complex, especially because of the increasing variety of demands from customers

* Please assign reference
** 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.

* Good informative chapter!
** '''I have now added references'''

== Construction projects ==
* A reference is needed for this.
** Because construction projects are usually experiencing delays and budget overruns, requirements have to be tracked in a satisfactory way

=== Overall impression of the ''Application context'' ===
* Very good idea to present different aspects, where Requirement management is relevant!
* Overall a very good chapter, but there is a lack of references.

== Requirements elicitation==
* Very good chapter, easy to understand.
== Requirements analysis ==
* Very well written section, but it would be very nice with a discussion regarding the Strength and weaknesses etc..

== Requirements change management ==
* Very interesting aspect to consider!
* There are no references assigned to this section.
** '''I have now assigned my references'''

=Overall feedback=
* Please read the article for grammatical errors (not many, but a few).
* I would properly introduce the section "Main steps of requirements management" earlier so when reading the different areas, where this approach is relevant the reader will already have an idea of what it is.
** '''You are right, it makes more sense to explain the steps first, and add the application chapter as examples in the end.'''
* Please be more critical throughout the article
** state strength, weaknesses and controversial points.
*** '''I wrote my article as an 'introduction and overview' article. It is open to discussion but I do not think it is the purpose of my article.'''
* An example for how to apply requirements management would be very nice, so the reader could get an idea of how to implement this in his/her project.
* An overall comment is that there a missing a lot of references, when doing this kind of article.
* Please be aware of copy&paste.
* Please attach "categories".
** '''Two categories were already attached.'''

= MartinKruck peer review =

= Formal aspect =

'''References'''
As mentioned by NobodyKnows, you should remember to use references.

'''Language'''
When rereading your article be mindful of your english, especially when using the suffix -s
e.g.: "As a matter of fact, a new designed product need (not:needs) to fulfil the customer’s expectations"
* '''why not needs? I do not understand this rule...'''

As mentioned by NobodyKnows, you should not use acronyms (don't, shouldn't). But I am sure that was just a slip up, since it only happened once ;-)
* '''Now corrected!'''

Also remember that [:] forces capital on the following letter. You have a title saying: "Requirements management: how to make a project successful?"
* '''I did not know this rule (in French, colons call for lowercase!). I think I corrected it everywhere.'''
Further more; this is not a question. Since this is the only title with a colon [:] it looks weird. Consider rewriting the other titles to the same format or rephrase the title to something like: How to make a successful using requirements management
* '''You are right, I did not really know how to turn this title. I think I have now found a better one.'''
Other than those I only stumbled a few times. 8/10 on your english.
* '''Thank you! That's good to know, I was kind of worried about this :\'''

'''Figures'''
I feel that most of your partitions could use some figures to illustrate their points, especially chapter 3 and 4, where you discuss some very valid points, which are also though to read since they are very complex.
* '''You are absolutely right. I know I should put figures and I would have liked to add some but unfortunately I could not find very accurate ones and I lacked time, so I wanted to focus on the text...'''

= Content =

Chapter 1 gives a great definition of the subject, but does not give a great summary of what is to come.

Chapter 2 is very well written and could only benefit from a few useful figures.

Chapter 3 loses some of its focus. I think that starting each topic with a '''short''' presentation on what each project is about and what/how requirements management is to be used, would help this part.

Chapter 4 is a bit confusing. I think that you should look further into your use of layout and/or use appropriate figures.

BTW you mention stakeholders. This subject is covered [[Mapping Stakeholders]] code: <nowiki>[[Mapping Stakeholders]]</nowiki>
* '''There are a lot of wiki articles about stakeholders! But I will try to find one to link here, because it is relevant.'''

Otherwise I think that the article is great and gave me some new knowledge. Keep up the good work!
* '''Thank you very much for your review! I also learnt a lot when doing this article ;)'''

Requirements management

2014-12-01T13:20:42Z

Eniram: /* Requirements change management */

= Overview =

According to The Office of Government Commerce in United Kingdom, 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”''<ref name="ogc">Office of Government Commerce, UK, ''Requirements Management'', available online: http://webarchive.nationalarchives.gov.uk/20100609111548/http://www.ogc.gov.uk/delivery_lifecycle_requirements_management.asp</ref>.

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 and 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 the entire 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<ref name="un">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</ref>. 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. 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, as well as ready 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<ref name="deux">Standish Group Report ''Chaos'', www.standishgroup.com (available free from many educational sources on the web)</ref>: Delayed projects, budget overruns, or products that do not 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 as a key for successful projects =

== 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 customers' and other stakeholders' 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.<ref name=''success''>Aaron, S.J., Don, D., Ofer, L., Alan, M.C., 2001. ''Project success: amultidimensional strategic concept.'' Long Range Plann. 34 (6), 699–725. </ref> 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 fulfilment of its needs, resulting in customer's satisfaction and loyalty. A customer can be any stakeholder with a strong interest in the project, who requires the services of the project management team, and usually who provides resources for the project.

* 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<ref name="deux"/>:

* 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<ref name="cinq"/>.

= Main steps of requirements management =

== Requirements elicitation ==

The requirements for a project can come from different possible sources, for example<ref name="cinq">Andrew Bourne, ''System Requirements Management'', Tube Lines Ltd., UK</ref>:

* 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. A [[Stakeholder Analysis]] will allow defining all the relevant stakeholders.

Requirements elicitation consists in understanding the needs of the stakeholders or any source of requirements and collecting them for future analysis<ref name="six">Alan M. Davis, Ed Yourdon, Ann S. Zweig, ''Requirements Management Made Easy'', Omni-Vista, Inc.</ref>. 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<ref name="trois"/>.

== 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<ref name="sept">Bashar Nuseibeh, Steve Easterbrook, ''Requirements Engineering: A Roadmap''</ref>. The elicited requirements need to be kept fully accessible<ref name="quatre"/> 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<ref name="un"/><ref name="trois"/>:

* 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<ref name="trois"/>.

All different requirements need to be ranked, which means that there is a need to know what the most important requirements are, and which of these requirements have to be prioritised<ref name="huit">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</ref> . 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<ref>Office of Government Commerce, UK, 'Managing changes to requirements', available online: http://webarchive.nationalarchives.gov.uk/20100503135839/http:/www.ogc.gov.uk/delivery_lifecycle_managing_changes_to_requirements.asp</ref>, mainly due to uncertainty and [[complexity]] in projects, and some examples of circumstances 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. Traceability is one of the main ways to identify, understand and support a change and its impact. The success in requirements management practices comes from the ability to accommodate such changes successfully. The inability to manage these changing requirements is often considered as a cause for project failure, impacting both cost and duration<ref name="deux"/>.
Of course, managing changes appears to be the most difficult task in requirements management.

= Application context =

Requirements management is a practice which is relevant in any kind of projects, even if it takes different proportions when speaking about systems engineering or project management.
In systems engineering, requirements management appears as the first key input of any process, but it is also a well justified practice in project management, for instance in product development projects or construction projects.

A comparative approach between systems engineering and project management can be found on this [http://apppm.man.dtu.dk/index.php/Systems_Engineering_versus_Project_Management,_a_comparative_study page].

== System engineering processes<ref name="trois"> ''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</ref> ==

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, and the first step of any 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.<ref name="product"> Nigel Cross, ''Engineering Design Methods: Strategies for Product Design'', the Open University, Milton Keynes, UK</ref> 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<ref name="product"/>, 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 facilitates 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 clients' requirements. Client's requirements constitute the main source of information for any construction project<ref name="CRP">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</ref>. The proposed or constructed facility must satisfy the clients' 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. Clients' 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<ref name="quatre">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.</ref>.

= References =

<references />

[[Category:Project Management]][[Category:Systems engineering]]

Requirements management

2014-12-01T13:20:12Z

Eniram: /* Requirements elicitation */

= Overview =

According to The Office of Government Commerce in United Kingdom, 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”''<ref name="ogc">Office of Government Commerce, UK, ''Requirements Management'', available online: http://webarchive.nationalarchives.gov.uk/20100609111548/http://www.ogc.gov.uk/delivery_lifecycle_requirements_management.asp</ref>.

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 and 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 the entire 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<ref name="un">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</ref>. 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. 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, as well as ready 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<ref name="deux">Standish Group Report ''Chaos'', www.standishgroup.com (available free from many educational sources on the web)</ref>: Delayed projects, budget overruns, or products that do not 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 as a key for successful projects =

== 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 customers' and other stakeholders' 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.<ref name=''success''>Aaron, S.J., Don, D., Ofer, L., Alan, M.C., 2001. ''Project success: amultidimensional strategic concept.'' Long Range Plann. 34 (6), 699–725. </ref> 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 fulfilment of its needs, resulting in customer's satisfaction and loyalty. A customer can be any stakeholder with a strong interest in the project, who requires the services of the project management team, and usually who provides resources for the project.

* 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<ref name="deux"/>:

* 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<ref name="cinq"/>.

= Main steps of requirements management =

== Requirements elicitation ==

The requirements for a project can come from different possible sources, for example<ref name="cinq">Andrew Bourne, ''System Requirements Management'', Tube Lines Ltd., UK</ref>:

* 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. A [[Stakeholder Analysis]] will allow defining all the relevant stakeholders.

Requirements elicitation consists in understanding the needs of the stakeholders or any source of requirements and collecting them for future analysis<ref name="six">Alan M. Davis, Ed Yourdon, Ann S. Zweig, ''Requirements Management Made Easy'', Omni-Vista, Inc.</ref>. 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<ref name="trois"/>.

== 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<ref name="sept">Bashar Nuseibeh, Steve Easterbrook, ''Requirements Engineering: A Roadmap''</ref>. The elicited requirements need to be kept fully accessible<ref name="quatre"/> 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<ref name="un"/><ref name="trois"/>:

* 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<ref name="trois"/>.

All different requirements need to be ranked, which means that there is a need to know what the most important requirements are, and which of these requirements have to be prioritised<ref name="huit">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</ref> . 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<ref>Office of Government Commerce, UK, 'Managing changes to requirements', available online: http://webarchive.nationalarchives.gov.uk/20100503135839/http:/www.ogc.gov.uk/delivery_lifecycle_managing_changes_to_requirements.asp</ref>, mainly due to uncertainty and complexity in projects, and some examples of circumstances 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. Traceability is one of the main ways to identify, understand and support a change and its impact. The success in requirements management practices comes from the ability to accommodate such changes successfully. The inability to manage these changing requirements is often considered as a cause for project failure, impacting both cost and duration<ref name="deux"/>.
Of course, managing changes appears to be the most difficult task in requirements management.

= Application context =

Requirements management is a practice which is relevant in any kind of projects, even if it takes different proportions when speaking about systems engineering or project management.
In systems engineering, requirements management appears as the first key input of any process, but it is also a well justified practice in project management, for instance in product development projects or construction projects.

A comparative approach between systems engineering and project management can be found on this [http://apppm.man.dtu.dk/index.php/Systems_Engineering_versus_Project_Management,_a_comparative_study page].

== System engineering processes<ref name="trois"> ''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</ref> ==

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, and the first step of any 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.<ref name="product"> Nigel Cross, ''Engineering Design Methods: Strategies for Product Design'', the Open University, Milton Keynes, UK</ref> 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<ref name="product"/>, 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 facilitates 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 clients' requirements. Client's requirements constitute the main source of information for any construction project<ref name="CRP">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</ref>. The proposed or constructed facility must satisfy the clients' 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. Clients' 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<ref name="quatre">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.</ref>.

= References =

<references />

[[Category:Project Management]][[Category:Systems engineering]]

Eniram: /* Definition of project success */

= Overview =

According to The Office of Government Commerce in United Kingdom, 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 and 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 the entire 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<ref name="un">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</ref>. 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. 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, as well as ready 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 <ref name="deux">Standish Group Report ''Chaos'', www.standishgroup.com (available free from many educational sources on the web)</ref> : 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.<ref name=''success''>Aaron, S.J., Don, D., Ofer, L., Alan, M.C., 2001. ''Project success: amultidimensional strategic concept.'' Long Range Plann. 34 (6), 699–725. </ref> 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 fulfilment 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<ref name="deux"/>:

- 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<ref name="cinq"/>.

= 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<ref name="trois"> ''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</ref> ==

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<ref name="CRP">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</ref>. 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<ref name="quatre">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.</ref>.

= Main steps of requirements management =

== Requirements elicitation ==

The requirements for a project can come from different possible sources, for example<ref name="cinq">Andrew Bourne, ''System Requirements Management'', Tube Lines Ltd., UK</ref>:

- 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<ref name="six">Alan M. Davis, Ed Yourdon, Ann S. Zweig, ''Requirements Management Made Easy'', Omni-Vista, Inc.</ref>. 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<ref name="trois"/>.

== 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<ref name="sept">Bashar Nuseibeh, Steve Easterbrook, ''Requirements Engineering: A Roadmap''</ref>. The elicited requirements need to be kept fully accessible<ref name="quatre"/> 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<ref name="un"/><ref name="trois"/>:

- 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<ref name="trois"/>.

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<ref name="huit">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</ref> . 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 =

<references />

[[Category:Project Management]][[Category:Systems engineering]]

Requirements management

2014-11-24T16:09:42Z

Eniram: /* Definition of project success */

= Overview =

According to The Office of Government Commerce in United Kingdom, 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 and 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 the entire 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<ref name="un">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</ref>. 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. 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, as well as ready 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 <ref name="deux">Standish Group Report ''Chaos'', www.standishgroup.com (available free from many educational sources on the web)</ref> : 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.<ref name=''success''>Aaron, S.J., Don, D., Ofer, L., Alan, M.C., 2001. ''Project success: amultidimensional strategic concept.'' Long Range Plann. 34 (6), 699–725. </ref> 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 fulfillment 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<ref name="deux"/>:

- 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<ref name="cinq"/>.

= 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<ref name="trois"> ''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</ref> ==

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<ref name="CRP">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</ref>. 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<ref name="quatre">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.</ref>.

= Main steps of requirements management =

== Requirements elicitation ==

The requirements for a project can come from different possible sources, for example<ref name="cinq">Andrew Bourne, ''System Requirements Management'', Tube Lines Ltd., UK</ref>:

- 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<ref name="six">Alan M. Davis, Ed Yourdon, Ann S. Zweig, ''Requirements Management Made Easy'', Omni-Vista, Inc.</ref>. 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<ref name="trois"/>.

== 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<ref name="sept">Bashar Nuseibeh, Steve Easterbrook, ''Requirements Engineering: A Roadmap''</ref>. The elicited requirements need to be kept fully accessible<ref name="quatre"/> 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<ref name="un"/><ref name="trois"/>:

- 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<ref name="trois"/>.

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<ref name="huit">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</ref> . 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 =

<references />

[[Category:Project Management]][[Category:Systems engineering]]