Jump to content

User:AndreaArzer/Requirements engineering

From Wikipedia, the free encyclopedia

Requirements engineering

[edit]
A graphical representation of the three dimensions of requirements engineering and a potential project path. [1]

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process.[2] It is a common process found within systems engineering and software engineering and prevalent within all technical industry standards.[3]The goal of requirements engineering is to improve the understanding of a proposed system, or system-to-be, by developing accurate, precise, and comprehensive requirements.[4] Requirements engineering consists of the following activities: elicitation, evaluation & agreement, specification, consolidation & validation, and management.[5]

Requirements engineers start with an opaque understanding of the system from the personal points of view of the system's stakeholders from which the requirements are elicited, and the representation is generally informal.[1] Through requirements analysis, (which the IREB considers to be a synonym of requirements engineering as well as a subsection of the requirements engineering cycle)[6] in conjunction with stakeholders, requirements engineers work towards the desired output: a complete representation of the system, based on agreements between stakeholders, and formally stated to limit ambiguities and confusion.[1]

History

[edit]

The first use of the term requirements engineering is believed to have been in the conference paper "Maintenance, Maintainability, and System Requirements Engineering", published in 1964.[7] In the early 1990's requirements engineering became recognized as a distinct professional discipline[8], but it did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial in March 1997.[7] Prior to this however, there was the International Symposium on Requirements Engineering in 1993 where the main focus was to provide an outlet for the best papers on requirements engineering.[8] A year later a conference series on requirements engineering was established that has since evolved into the International Conference on Requirements Engineering.[7] At the 2000 edition of the International Conference on Requirements Engineering, discussions of a merger of the two conferences started. In 2001, the merger of these two conferences became official and the name of the conference was the International Requirements Engineering Conference.[8]

Requirements engineering is presented as the first phase of the development process in the waterfall model.[9] Later development methods, including the Rational Unified Process (RUP) for software, assume that requirements engineering continues through a system's lifetime.[10]

Requirements

[edit]
Different types of requirements.[11]

Main article: Requirements

Within requirements engineering, requirements concerning a system's functionality are generally distinct from other requirements, the main distinction between a functional or a non-functional requirement. Requirements can be further divided into functional requirements, performance requirements, specific quality requirements, and constraints.[11]

Functional requirements are mainly focused on what a product must do or what a system should be able to perform.[11] They are the description of behavioral aspects and can be described as a specification of behavior between inputs and outputs.[12] Other than behavioral aspects, functional requirements are also characterized by stimuli, reactions, and data.[11]

Non-functional requirements define the qualities that a system is supposed to have.[13] Examples of non-functional requirements include: compliance, efficiency, effectiveness, response time, and scalability.

A non-functional requirement is either an attribute or a constraint. Within attributes, performance requirements pertain to performance concerns and have to do with aspects such as throughput and timing. Other attributes include specific quality requirements, which pertain to quality concerns other than the quality of functional requirements. A constraint is a requirement that constrains the solution space; these limit the system, define what is relevant, and shape the scope of the system. In other words, non-functional requirements describe the non-behavioral aspects of a system, capturing properties and constraints under which a system must operate.[11]

Non-functional requirements can generally be divided into execution qualities and evolution qualities. The former is concerned with aspects such as usability and security; these aspects are observable at run time. The latter is concerned with aspects such as testability and maintainability.[13][14]

Requirements engineering cycle

[edit]
The iterative cycle of requirements engineering.[5]

The activities involved in requirements engineering may vary depending on the type of system being developed and the organization's specific practice(s), but there is a general roadmap that many requirements engineering projects follow. Generally, the bulk of requirements engineering is done before other steps in the development process to establish a common understanding of the context, the system-to-be, and the development priorities.[4] The phases named and described below are interrelated and non-linear; activity that is related to one phase may advance or backtrack progress on another phase.[5] The terms used to describe the phases and the grouping of techniques within the phases may be rearranged in specific instances of implementation. Requirements Analysis, when not understood as a synonym of requirements engineering, is a subsection of requirements engineering that focuses on the optimization of requirements after elicitation.

Some engineering fields (or specific situations) require the product to be completely designed and modeled before development, requiring the design phase to be performed in advance, similar to how blueprints for a building must be completed before a construction contract can be approved and signed.[5]

Elicitation

[edit]

Requirements elicitation is the process of discovering and otherwise identifying candidate requirements and assumptions based on interactions with stakeholders of the proposed system.[5] This phase of requirements engineering depends on effective communication and should be a cooperative process between the stakeholders and the requirements engineer to develop a shared understanding of the needs, context, and vision of the project.[15]

The fundamental activities during elicitation are: [16]

  • Building an understanding of the system domain - To support consensus and accuracy of requirements, requirements engineers should investigate the context of the current system to find relevant constraints and current problems.
  • Identifying sources of requirements - Requirements can be elicited from interviews with stakeholders, users, or subject matter experts. They can also be elicited from existing or legacy systems, current processes, and documentation.
  • Analyzing the stakeholders - It may be helpful to prioritize the stakeholders, and the requirements elicited from them, based on the stakeholder's importance to the system-to-be.
  • Selecting techniques and tools - Using multiple elicitation techniques can lead to more thorough requirements. Elicitation techniques have been borrowed and adapted from other disciplines such as social sciences, organizational theory, group dynamics, and knowledge engineering.
  • Eliciting requirements

Evaluation & agreement

[edit]

The evaluation and agreement stage focuses on the identification of conflicting concerns and risks, as well as comparisons between alternatives. Through different methods of evaluation, needs and options can be prioritized and weighed within the context of the proposed system.[5] When working with limited resources, it's important to prioritize requirements to develop the most important elements in an efficient manner, with the aim of getting the highest value for the lowest cost.[17] Within this phase, strategies from the fields of decision theory and risk management can help evaluate alternative options. Both written and graphical tools can be used as aids; written analysis tools include use cases and user stories, and graphical tools include UML and LML.

Specification

[edit]

The specification phase of requirements engineering emphasizes the formalization of the requirements. Requirements should be documented, detailed, and structured so the document is understandable to relevant stakeholders.[5] Requirements can be documented in a formal artifact called a Requirements Specification (RS), exemplified by a Software requirements specification (SRS), which can contain structured language, diagrams, and formal specifications.

User stories are a concise, structured notation used to express requirements, increasingly employed in agile development.[18] User stories capture the essential elements of a requirement: who it is for, what that user/stakeholder expects from the system, and why that expectation is important.[19] In agile development, user stories are the most used method of representing and documenting requirements, preferred by nearly 73% of requirements analysts.[20]

IEEE Recommended Practice for Software Requirements Specifications defines eight important characteristics for a requirement: correct, unambiguous, complete, consistent, ranked for importance/stability, verifiable, modifiable, and traceable.[21]

Consolidation & validation

[edit]

Requirements consolidation and validation focuses on checking that the documented requirements and models are consistent and meet the stakeholders' needs. It’s important to verify that stakeholders’ desires and needs are adequately covered by the requirements, that there’s agreement between stakeholders, and that context assumptions are reasonable.[15] This is also the stage to evaluate the comprehensiveness of the RS and to identify and rectify any inconsistencies or omissions. To support requirements engineers, some consolidation and validation elements can be initially [evaluated with NLP] (*link to currently unpublished 'NLP for RE' Wikipedia page*); some techniques base this evaluation on the Quality User Story framework which determines the quality of user stories in terms of syntax, pragmatics, and semantics.[19]

Management

[edit]

Requirements management, the connection between requirements engineering and the development of the proposed system, is a sub-function of Systems Engineering practices. Systems and their requirements change over time due to changing business processes, competitors and their actions, changing priorities, changing technology, changing laws/regulations, different stakeholder needs, or feedback from users.[15] Requirements management includes storing, changing and tracing requirements, as well as supervising the system as it is developed and implemented to ensure that requirements remain accurate and relevant. As such, requirements management is the connection between requirements development and the development of the proposed system.[22]

Requirements engineering tools

[edit]

The different stages of requirements engineering contain complex activities, and each stage relies on human decisions, making automating them more complicated. However, new tools and software are developed and updated regularly to support the requirements engineering process through its different stages; studies have found 100 different tools throughout requirements engineering resources on the Internet. Tools and software support the different requirements engineering stages with capabilities and features focused on requirements elicitation, requirements analysis, requirements specification, requirements modeling, goal modeling, requirements verification and validation, requirements management, requirements traceability and other capabilities. [23][24] These applications are often referred to as requirements engineering tools and can be classified by their different capabilities and purposes according to the ISO/IEC TR 24766:2009 standard.

For more information and an extended list of available requirements engineering tools, as well as their classification and capabilities in detail, see Requirements Engineering Tools.

Common challenges and possible solutions

[edit]

As requirements are the foundation that projects are built on, organizations benefit from being able to identify and prevent mistakes as early as possible during the requirements engineering phase.[25] A reported 48% of problems identified during development can be traced back to inadequate requirements engineering[26] and the further along in the development stage a requirement-related problem is discovered, the higher the rework costs can be.[27] Therefore, this chapter displays requirements problems often addressed in literature, as well as how agile methodology could help prevent encountering some problems.[28]

Scope creep and over-scoping

[edit]

Requirements are constantly discovered, changed, evolved and discarded.[28] Unforeseen changes can increase the time and cost required for development and unmanaged and unexpected changes to the scope can lead to problems in already existing architectures, designs, implementations and tests.[29] Therefore, it is important to prevent scope creep, an uncontrolled growth of the scope, and to define what changes will be accepted in what time frame.[30] Over-scoping happens when the scope of the project is larger than the provided resources can handle; this can, amongst other reasons, be caused by miscommunication, requirement changes, quality issues, and a lack of stakeholder involvement in the different stages of the process that limits their ability to indicate unwanted or out-of-scope requirements.[31]

Quality issues of requirements

[edit]

If requirements are documented inadequately, there can be consequences for the entire requirements engineering cycle, as they need to be reworked at later stages, and can increase development and sustainment costs and cause schedule overruns.[29] The following table shows common undesirable qualities of requirements that were mentioned in multiple studies. Much of the research on this topic has focused on requirements engineering in the field of software development.

Common Undesirable Qualities of Requirements
Quality Issue of the requirement Definition Source
Ambiguous The requirement statement can have several different meaning and be interpreted in different ways. [5][16][32][29][33]
Incomplete or missing The requirements do not cover the entire scope of functionalities and/or features required. [5][16][34][35][36]
Incorrect The requirement does not accurately describe the functionality to be built. [16][32][29][37][38]
Inconsistent The requirement conflicts or contradicts other requirements or the required behavior of the system. [5][16][32][29][34]
Unfeasible The requirement cannot be implemented within the capabilities and limitations of the system and/or other project constraints. [5][16][32][29][33]
Unintelligible The requirement that incomprehensible for the people that need to work with it. [5][29]
Irrelevant The requirement is not actually needed to build the required system. [29]
Unverifiable The requirement can not be verified by examination, analysis, test, or demonstration. [5][29]
Inappropriate constraints The requirement is stated in a way that it describes how to build the system rather than what and how the system should do something. [5][29][33][35][36]
Untraceable The source of the requirement, the relationship to other requirements are not documented. [29][26][28][39][40]

Inadequate communication and customer involvement

[edit]

Communication problems and gaps, where required information is not provided to the necessary people, are common problems when interacting with stakeholders.[28][31] Communication gaps can happen when stakeholders are unclear about their own needs,[41][42] when erroneous assumptions are made, or when seemingly obvious information is omitted.[16][42] Furthermore, the interplay between culture, conflict, and distance in globally-distributed requirements negotiations[16][42] and undefined vocabulary, use of domain specific terminology and missing domain knowledge can lead to misunderstandings between stakeholders and the project team.[16][38] These challenges can cause problems during modeling, design, and implementation.[43] Additionally, if stakeholders are involved only during the early stages of the requirements cycle and requirements are discovered at later stages, they might not be integrable and could cause problems in the negotiation and validation of requirements.[32][34]

Inadequate validation and verification of requirements quality

[edit]

Requirements need to be validated and verified to ensure that they are complete and accurate. Requirements validation may be skipped due to a lack of stakeholder time, tight project schedule, or low project funding, leading to incomplete or incorrect requirements and a finished product that does not reflect the stakeholder's needs.[29] When eventually discovered, requirement defects will be significantly more expensive and time intensive to fix than they would have been had they been fixed during early requirements verification.[29][35]

Tackling the challenges with agile methods

[edit]

Research discusses several possible ways of coping with the challenges of requirements engineering; agile development methodology is the most frequently mentioned possible solution.[44] Agile methods promote frequent face-to-face communication among cross-functional teams,[45] and the gradual detailing of requirements.[44] Additionally, as the customer is present during each step of the process, they are able to recommend changes or to give approval for further progress[28][44] and are constantly updated about the progress made and can provide timely feedback.[46] However, consistent client availability might not be feasible; experiential research studies have identified that customer availability can be an issue,[39][47] as the customer must consider cost, time, and available workday bandwidth.[48]

Requirements validation and ensuring requirement quality could be eased by agile methods as well since continuous prioritization is an essential part of these methods;[49] at the end of every sprint, a requirement is demonstrated to customer representatives who can review and suggest changes to ensure that the requirements satisfy their needs.[28] While some agile practices utilize continuous testing,[39] consistent checking or inspection of the requirements is rarely done during agile requirements engineering.[50]

The International Requirements Engineering Board

[edit]

The International Requirements Engineering Board (IREB) e.V. is an independent, non-profit organization founded in 2006 in Germany by leading requirements engineering representatives from science, research, industry, and consulting. Their goals were to create an internationally accepted and professional basis for requirements engineering, foster further education, and improve requirements engineering and business analysis in practice.

To reach their goals, IREB established an international accepted qualification - the Certified Professional for Requirements Engineering (CPRE). This three-tier qualification is an international certification for professionals in the fields of requirements engineering, business analysis, and software and systems development, and is regulated by the steering committee of IREB, consisting of international requirements engineering experts from universities, industry, and education. The concepts are taught by independent training providers and the exam is administered at approved certification bodies. These regulations ensure that the CPRE follows ISO/IEC 17024:2012 standard, which requires the strict separation of training and certification. IREB has also created the CPRE Glossary, which eases the communication amongst the people involved in the requirements engineering process.[51]

Requirements engineer as a role

[edit]

According to IREB, a requirements engineer is “a person who — in collaboration with stakeholders — elicits, documents, validates, and manages requirements.”[6] However, according to literature, jobs are rarely titled as Requirements Engineer and the role itself is not defined clearly.[52] Therefore, the tasks performed vary for requirements engineers depending on the organizational structure, project circumstances or personal capabilities.[53][54] Chong Wang, Pengwei Cui, Maya Daneva, and Mohamad Kassab stated that, even if requirements engineer is described as a profession, “there is a significant incongruity regarding the perceptions of the requirements engineering role, tasks, and responsibilities in the IT marketplace.”[55] Often, a requirements engineer is assigned by their organization either due to some other role or position they currently hold in the project, on a case-by-case basis, or the role and its tasks are distributed amongst different roles.[56]

The following positions may be involved in requirements engineering and hold related responsibilities: executive, software or solution architect, consultant, project manager, system designer, business/data/application analyst, and technical specialist, scrum master or product owner function support, coordinator, information-management advisor.[57][58] Requirements engineering is mostly done by analysts and consultants, followed by project managers; together, those titles account for 77% of all requirements engineering related positions found.[57]

Applicable standards

[edit]

Below is a selection of standards that apply to the requirements engineering cycle:

Active standards

[edit]
  • ISO/IEC/IEEE 15288-2015: Systems and software engineering - System life cycle processes[61][62]
  • ISO/IEC/IEEE 24765-2017: Systems and software engineering - Vocabulary[63][64]
  • ISO/IEC/IEEE 29148-2018: International Standard -Systems and software engineering - Life cycle processes - Requirements engineering[65][66]
  • ISO/IEC TR 24766:2009: Information technology - Systems and software engineering - Guide for requirements engineering tool capabilities[67]
  • ISO/IEC 25001:2014: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Planning and management[68]
  • ISO/IEC 25010:2011: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models[69]
  • ISO/IEC TS 25011:2017: Information technology - Systems and software Quality Requirements and Evaluation (SQuaRE) - Service quality models[70]
  • ISO/IEC 25012:2008: Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Data quality modelISO/IEC 25020:2019: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality measurement framework[71]
  • ISO/IEC 25020:2019: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality measurement framework[72]
  • ISO/IEC 25021:2012: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality measure elements[73]
  • ISO/IEC 25022:2016: Systems and software engineering - Systems and software quality requirements and evaluation (SQuaRE) Measurement of quality in use[74]
  • ISO/IEC 25023:2016: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of system and software product quality[75]
  • ISO/IEC 25024:2015: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data quality[76]
  • ISO/IEC TS 25025:2021: Information technology - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of IT service quality[77]
  • ISO/IEC 25030: Systems and software engineering - Systems and software quality requirements and evaluation (SQuaRE) - Quality requirements framework[78]
  • ISO/IEC 25041:2012: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation guide for developers, acquirers and independent evaluators[79]

Inactive standards:

[edit]
  • IEEE 830-1998: IEEE Recommended Practice for Software Requirements Specifications (Replaced by ISO/IEC/IEEE 29148:2011)[80]
  • ISO/IEC 12119:1994: Information technology — Software packages — Quality requirements and testing[81]
  • IEEE 1465-1998: IEEE Standard - Adoption of International Standard ISO/IEC 12119:1994(E) - Information Technology - Software Packages - Quality Requirements and Testing[82]
[edit]

Requirements engineering draws on various cognitive and social sciences to provide theoretical grounding and practical techniques. Cognitive psychology can inform requirements engineers about the difficulties people may experience when describing their wants and needs. Anthropology provides a methodological approach to observing human activities, which helps with developing a rich understanding of needs for a proposed product. Sociology also provides an understanding of political and cultural changes that might impact a proposed system. Linguistics is important for requirements engineering since the field hinges on accurate communication. Linguistic analyses have changed the way language is used in specifications to avoid ambiguity or to enhance understandability.[4]

See also

[edit]

References

[edit]
  1. ^ a b c Pohl, Klaus (April 1994). "The three dimensions of requirements engineering: A framework and its applications". Information Systems. 19 (3): 243–258. doi:10.1016/0306-4379(94)90044-2.
  2. ^ Chemuturi, Murali (2013). Requirements Engineering and Management for Software Development Projects. New York, NY: Springer New York. doi:10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654.
  3. ^ Boulanger, Jean-Louis (2016), "Requirement Management", Certifiable Software Applications 1, Elsevier, pp. 239–282, doi:10.1016/b978-1-78548-117-8.50010-6, ISBN 978-1-78548-117-8, retrieved 2023-01-13
  4. ^ a b c Nuseibeh, Bashar; Easterbrook, Steve (2000-05-01). "Requirements engineering: a roadmap". Proceedings of the Conference on the Future of Software Engineering. ICSE '00. New York, NY, USA: Association for Computing Machinery: 35–46. doi:10.1145/336512.336523. ISBN 978-1-58113-253-3. S2CID 1646308.
  5. ^ a b c d e f g h i j k l m n van Lamsweerde, Axel (2009). Requirements Engineering: From system goals to UML models to software specifications. Wiley. pp. 3–60. ISBN 978-8126545896.
  6. ^ a b Board, International Requirements Engineering. "CPRE Glossary - CPRE - IREB". International Requirements Engineering Board. Retrieved 2023-01-13.
  7. ^ a b c Dresner, J.; Borchers, K. H. (1964-01-01). "Maintenance, Maintainability, and System Requirements Engineering". SAE Technical Paper Series. Vol. 1. p. 640591. doi:10.4271/640591.
  8. ^ a b c 2013 21st IEEE International Requirements Engineering Conference (RE) : proceedings : July 15-19, 2013, Rio de Janeiro, Brasil. IEEE Computer Society, Institute of Electrical and Electronics Engineers. Piscataway, NJ. 2013. ISBN 978-1-4673-5765-4. OCLC 865456233.{{cite book}}: CS1 maint: location missing publisher (link) CS1 maint: others (link)
  9. ^ Royce, Winston W. (2021-02-02), "Managing the Development of Large Software Systems (1970)", Ideas That Created the Future, The MIT Press, pp. 321–332, doi:10.7551/mitpress/12274.003.0035, ISBN 9780262363174, S2CID 234019482, retrieved 2023-01-13
  10. ^ Kruchten, Philippe (2003). Rational Unified Process, The : An Introduction, Third Edition (3rd ed.). ISBN 9780321197702. OCLC 1204075196.
  11. ^ a b c d e Glinz, Martin (2007). "On Non-Functional Requirements". 15th IEEE International Requirements Engineering Conference (RE 2007): 21–26. doi:10.1109/RE.2007.45. ISBN 978-0-7695-2935-6. S2CID 7527008.
  12. ^ Fulton, Randall (2017). Airborne Electronic Hardware Design Assurance. Roy Vandermolen. [Place of publication not identified]: CRC Press. ISBN 978-1-351-83142-0. OCLC 1103274474.
  13. ^ a b Wiegers, Karl Eugene (2013). Software requirements. Joy Beatty (3rd ed.). Redmond, Washington. ISBN 978-0-7356-7962-7. OCLC 857497823.{{cite book}}: CS1 maint: location missing publisher (link)
  14. ^ Young, Ralph Rowland (2001). Effective requirements practices. Boston, Ma.: Addison-Wesley. ISBN 0-201-70912-0. OCLC 45460881.
  15. ^ a b c Roman, Adam (2018), "2018 Foundation Syllabus Overview", A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Cham: Springer International Publishing, pp. 3–11, doi:10.1007/978-3-319-98740-8_1, ISBN 978-3-319-98739-2, retrieved 2023-01-12
  16. ^ a b c d e f g h i Zowghi, Didar; Coulin, Chad (2005), Aurum, Aybüke; Wohlin, Claes (eds.), "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools", Engineering and Managing Software Requirements, Berlin/Heidelberg: Springer-Verlag, pp. 19–46, doi:10.1007/3-540-28244-0_2, hdl:10453/11626, ISBN 978-3-540-25043-2, retrieved 2023-01-12
  17. ^ Firesmith, Donald (2004). "Prioritizing Requirements". The Journal of Object Technology. 3 (8): 35. doi:10.5381/jot.2004.3.8.c4. ISSN 1660-1769.
  18. ^ Cao, Lan; Ramesh, Balasubramaniam (2008-01-07). "Agile Requirements Engineering Practices: An Empirical Study". IEEE Software. 25 (1): 60–67. doi:10.1109/MS.2008.1. ISSN 0740-7459. S2CID 110873299.
  19. ^ a b Lucassen, Garm; Dalpiaz, Fabiano; van der Werf, Jan Martijn E.M.; Brinkkemper, Sjaak (2015-11-05). "Forging high-quality User Stories: Towards a discipline for Agile Requirements". 2015 IEEE 23rd International Requirements Engineering Conference (RE). Ottawa, ON, Canada: IEEE: 126–135. doi:10.1109/RE.2015.7320415. ISBN 978-1-4673-6905-3. S2CID 820264.
  20. ^ Wang, Xinyu; Zhao, Liping; Wang, Ye; Sun, Jie (2014), Zowghi, Didar; Jin, Zhi (eds.), "The Role of Requirements Engineering Practices in Agile Development: An Empirical Study", Requirements Engineering, vol. 432, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 195–209, doi:10.1007/978-3-662-43610-3_15, ISBN 978-3-662-43609-7, retrieved 2023-01-12
  21. ^ IEEE Recommended Practice for Software Requirements Specifications. doi:10.1109/ieeestd.1994.121431. ISBN 0-7381-4723-0.
  22. ^ Requirements management : the interface between requirements development and all other systems engineering processes. Colin Hood. Berlin: Springer. 2008. ISBN 978-3-540-68476-3. OCLC 233973180.{{cite book}}: CS1 maint: others (link)
  23. ^ Carrillo de Gea, Juan M.; Nicolás, Joaquín; Fernández Alemán, José L.; Toval, Ambrosio; Ebert, Christof; Vizcaíno, Aurora (2012-10-01). "Requirements engineering tools: Capabilities, survey and assessment". Information and Software Technology. 54 (10): 1142–1157. doi:10.1016/j.infsof.2012.04.005. ISSN 0950-5849.
  24. ^ Matulevičius, Raimundas; Sindre, Guttorm (2006). Nilsson, Anders G.; Gustas, Remigijus; Wojtkowski, Wita; Wojtkowski, W. Gregory; Wrycza, Stanisław; Zupančič, Jože (eds.). "Requirements Engineering Tool Evaluation Approach". Advances in Information Systems Development. Boston, MA: Springer US: 695–706. doi:10.1007/978-0-387-36402-5_60. ISBN 978-0-387-36402-5.
  25. ^ Sommerville, Ian (2011). Software engineering (9th ed.). Boston: Pearson. ISBN 978-0-13-703515-1. OCLC 462909026.
  26. ^ a b Hall, T.; Beecham, S.; Rainer, A. (2002). "Requirements problems in twelve software companies: an empirical analysis". IEE Proceedings - Software. 149 (5): 153. doi:10.1049/ip-sen:20020694.
  27. ^ Boehm, B.W.; Papaccio, P.N. (October 1988). "Understanding and controlling software costs". IEEE Transactions on Software Engineering. 14 (10): 1462–1477. doi:10.1109/32.6191.
  28. ^ a b c d e f Inayat, Irum; Salim, Siti Salwah; Marczak, Sabrina; Daneva, Maya; Shamshirband, Shahaboddin (2015-10-01). "A systematic literature review on agile requirements engineering practices and challenges". Computers in Human Behavior. Computing for Human Learning, Behaviour and Collaboration in the Social and Mobile Networks Era. 51: 915–929. doi:10.1016/j.chb.2014.10.046. ISSN 0747-5632.
  29. ^ a b c d e f g h i j k l m Firesmith, Donald (2007). "Common Requirements Problems, Their Negative Consequences, and the Industry Best Practices to Help Solve Them". The Journal of Object Technology. 6 (1): 17. doi:10.5381/jot.2007.6.1.c2. ISSN 1660-1769.
  30. ^ DeMarco, T.; Lister, T. (September 2003). "Risk management during requirements". IEEE Software. 20 (5): 99–101. doi:10.1109/MS.2003.1231163. ISSN 0740-7459.
  31. ^ a b Bjarnason, Elizabeth; Wnuk, Krzysztof; Regnell, Björn (August 2011). "Requirements are slipping through the gaps — A case study on causes & effects of communication gaps in large-scale software development". 2011 IEEE 19th International Requirements Engineering Conference: 37–46. doi:10.1109/RE.2011.6051639. ISBN 978-1-4577-0921-0. S2CID 1298963.
  32. ^ a b c d e Shah, Tejas; V Patel, S (2014-08-20). "A Review of Requirement Engineering Issues and Challenges in Various Software Development Methods" (PDF). International Journal of Computer Applications. 99 (15): 36–45. doi:10.5120/17451-8370. ISSN 0975-8887.
  33. ^ a b c Wagner, Stefan; Fernández, Daniel Méndez; Felderer, Michael; Kalinowski, Marcos (2017-03-24). "Requirements Engineering Practice and Problems in Agile Projects: Results from an International Survey". arXiv:1703.08360. {{cite journal}}: Cite journal requires |journal= (help)
  34. ^ a b c Kalinowski, Marcos; Spinola, Rodrigo; Conte, Tayana; Prikladnicki, Rafael; Fernández, Daniel Méndez; Wagner, Stefan (2015-07-01). "Towards Building Knowledge on Causes of Critical Requirements Engineering Problems" (PDF). Proceedings of the 27th International Conference on Software Engineering and Knowledge Engineering. Vol. 2015. pp. 1–6. doi:10.18293/SEKE2015-220. ISBN 978-1-891706-37-0.
  35. ^ a b c Lawrence, Brian; Wiegers, Karl; Ebert, Christof (November 2001). "The Top Risks of Requirements Engineering". IEEE Software. 18 (6): 62–63. doi:10.1109/52.965804.
  36. ^ a b Mafra, Priscilla; Kalinowski, Marcos; Mendez Fernandez, Daniel; Felderer, Michael; Wagner, Stefan (August 2016). "Towards Guidelines for Preventing Critical Requirements Engineering Problems". 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). Limassol: IEEE: 25–29. arXiv:1611.08833. doi:10.1109/SEAA.2016.50. ISBN 978-1-5090-2820-7. S2CID 6833980.
  37. ^ Palmer, James D.; Liang, Yiquing; Want, Lillian (1990-10-06). "Classification as an Approach To Requirements Analysis". Proceedings of the 1st ASIS SIG/CR Classification Research Workshop: 131–138. doi:10.7152/acro.v1i1.12472 (inactive 2023-01-23).{{cite journal}}: CS1 maint: DOI inactive as of January 2023 (link)
  38. ^ a b Apshvalka, Dace; Donina, Dace; Kirikova, Marite (2009), Wojtkowski, Wita; Wojtkowski, Gregory; Lang, Michael; Conboy, Kieran (eds.), "Understanding the Problems of Requirements Elicitation Process: A Human Perspective", Information Systems Development, Boston, MA: Springer US, pp. 211–223, doi:10.1007/978-0-387-68772-8_17, ISBN 978-0-387-30403-8, retrieved 2023-01-13
  39. ^ a b c Ramesh, Balasubramaniam; Cao, Lan; Baskerville, Richard (2007-11-13). "Agile requirements engineering practices and challenges: an empirical study". Information Systems Journal. 20 (5): 449–480. doi:10.1111/j.1365-2575.2007.00259.x. S2CID 31537928.
  40. ^ Karlsson, Lena; Dahlstedt, Åsa G.; Regnell, Björn; Natt och Dag, Johan; Persson, Anne (2007-06-01). "Requirements engineering challenges in market-driven software development – An interview study with practitioners". Information and Software Technology. Qualitative Software Engineering Research. 49 (6): 588–604. doi:10.1016/j.infsof.2007.02.008. ISSN 0950-5849.
  41. ^ Naz, Humaira; Khokhar, Muhammad Nadeem (February 2009). "Critical Requirements Engineering Issues and their Solution". 2009 International Conference on Computer Modeling and Simulation: 218–222. doi:10.1109/ICCMS.2009.50. ISBN 978-0-7695-3562-3. S2CID 2874812.
  42. ^ a b c Wahono, Romi Satria (January 2003). "Analyzing Requirements Engineering Problems". Proceedings of the IECI Japan Workshop 2003: 55–58. ISSN 1344-7491.
  43. ^ Damian, D.E.; Zowghi, D. (January 2003). "An insight into the interplay between culture, conflict and distance in globally distributed requirements negotiations". 36th Annual Hawaii International Conference on System Sciences, 2003. Proceedings of the: 10 pp.–. doi:10.1109/HICSS.2003.1173665. hdl:10453/2439. ISBN 0-7695-1874-5. S2CID 16764540.
  44. ^ a b c Bjarnason, Elizabeth; Wnuk, Krzysztof; Regnell, Björn (2011-07-26). "A case study on benefits and side-effects of agile practices in large-scale requirements engineering". Proceedings of the 1st Workshop on Agile Requirements Engineering. AREW '11. New York, NY, USA: Association for Computing Machinery: 1–5. doi:10.1145/2068783.2068786. ISBN 978-1-4503-0890-8. S2CID 207191362.
  45. ^ Sillitti, A.; Ceschi, M.; Russo, B.; Succi, G. (2005). "Managing Uncertainty in Requirements: A Survey in Documentation-Driven and Agile Companies". 11th IEEE International Software Metrics Symposium (METRICS'05). Como, Italy: IEEE: 17. doi:10.1109/METRICS.2005.29. ISBN 978-0-7695-2371-2. S2CID 14389629.
  46. ^ Ming Huo; Verner, J.; Liming Zhu; Babar, M.A. (2004). "Software quality and agile methods". Proceedings of the 28th Annual International Computer Software and Applications Conference, 2004. COMPSAC 2004. Hong Kong: IEEE: 520–525. doi:10.1109/CMPSAC.2004.1342889. hdl:10344/2144. ISBN 978-0-7695-2209-8. S2CID 14342607.
  47. ^ Pichler, Mario; Rumetshofer, Hildegard; Wahler, Wilhelm (September 2006). "Agile Requirements Engineering for a Social Insurance for Occupational Risks Organization: A Case Study". 14th IEEE International Requirements Engineering Conference (RE'06): 251–256. doi:10.1109/RE.2006.8. ISBN 0-7695-2555-5. S2CID 23894137.
  48. ^ Racheva, Zornitza; Daneva, Maya; Herrmann, Andrea (2010-09-16). "A conceptual model of client-driven agile requirements prioritization: results of a case study". Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement. Bolzano-Bozen Italy: ACM: 1–4. doi:10.1145/1852786.1852837. ISBN 978-1-4503-0039-1. S2CID 8226224.
  49. ^ Hasnain, Eisha; Hall, Tracy (2009-05-08). "Introduction to Stand‐up Meetings in Agile Methods". AIP Conference Proceedings. 1127 (1): 110–120. doi:10.1063/1.3146182. ISSN 0094-243X.
  50. ^ Paetsch, F.; Eberlein, A.; Maurer, F. (2003). "Requirements engineering and agile software development". WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. Linz, Austria: IEEE Comput. Soc: 308–313. doi:10.1109/ENABL.2003.1231428. ISBN 978-0-7695-1963-0. S2CID 13610125.
  51. ^ Board, International Requirements Engineering. "IREB in depth - About IREB - IREB". International Requirements Engineering Board. Retrieved 2023-01-13.
  52. ^ Paech, Barbara (July 2008). "What Is a Requirements Engineer?". IEEE Software. 25 (4): 16–17. doi:10.1109/MS.2008.106. ISSN 0740-7459. S2CID 2287265.
  53. ^ Herrmann, Andrea (2013). Doerr, Joerg; Opdahl, Andreas L. (eds.). "Requirements Engineering in Practice: There Is No Requirements Engineer Position". Requirements Engineering: Foundation for Software Quality. Lecture Notes in Computer Science. 7830. Berlin, Heidelberg: Springer: 347–361. doi:10.1007/978-3-642-37422-7_25. ISBN 978-3-642-37422-7.
  54. ^ Aurum, Aybüke; Wohlin, Claes (2005), Aurum, Aybüke; Wohlin, Claes (eds.), "Requirements Engineering: Setting the Context", Engineering and Managing Software Requirements, Berlin, Heidelberg: Springer, pp. 1–15, doi:10.1007/3-540-28244-0_1, ISBN 978-3-540-28244-0, retrieved 2023-01-13
  55. ^ Wang, Chong; Cui, Pengwei; Daneva, Maya; Kassab, Mohamad (2018-10-11). "Understanding what industry wants from requirements engineers: an exploration of RE jobs in Canada". Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ESEM '18. New York, NY, USA: Association for Computing Machinery: 1–10. doi:10.1145/3239235.3268916. ISBN 978-1-4503-5823-1. S2CID 52937725.
  56. ^ Franch, Xavier; Palomares, Cristina; Gorschek, Tony (2021-05-24). "On the requirements engineer role". Communications of the ACM. 64 (6): 69–75. doi:10.1145/3418292. hdl:2117/363806. ISSN 0001-0782. S2CID 235171908.
  57. ^ a b Daneva, Maya; Wang, Chong; Hoener, Patrick (November 2017). "What the Job Market Wants from Requirements Engineers? An Empirical Analysis of Online Job Ads from the Netherlands". 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM): 448–453. doi:10.1109/ESEM.2017.60. ISBN 978-1-5090-4039-1. S2CID 4715363.
  58. ^ Neill, C.J.; Laplante, P.A. (November 2003). "Requirements engineering: The state of the practice". IEEE Software. 20 (6): 40–45. doi:10.1109/MS.2003.1241365. ISSN 0740-7459.
  59. ^ "ISO/IEC/IEEE International Standard - Systems and software engineering – Software life cycle processes". ISO/IEC/IEEE 12207:2017(E) First Edition 2017-11: 1–157. November 2017. doi:10.1109/IEEESTD.2017.8100771. ISBN 978-1-5044-4253-4.
  60. ^ 14:00-17:00. "ISO/IEC/IEEE 12207:2017". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  61. ^ "ISO/IEC/IEEE International Standard - Systems and software engineering – System life cycle processes". ISO/IEC/IEEE 15288 First Edition 2015-05-15: 1–118. May 2015. doi:10.1109/IEEESTD.2015.7106435. ISBN 978-0-7381-9531-5.
  62. ^ 14:00-17:00. "ISO/IEC/IEEE 15288:2015". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  63. ^ ISO/IEC/IEEE International Standard - Systems and software engineering–Vocabulary. August 2017. pp. 1–541. doi:10.1109/IEEESTD.2017.8016712. ISBN 978-1-5044-4118-6. {{cite book}}: |journal= ignored (help)
  64. ^ 14:00-17:00. "ISO/IEC/IEEE 24765:2017". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  65. ^ ISO/IEC/IEEE International Standard - Systems and software engineering – Life cycle processes – Requirements engineering. November 2018. pp. 1–104. doi:10.1109/IEEESTD.2018.8559686. ISBN 978-1-5044-5302-8. {{cite book}}: |journal= ignored (help)
  66. ^ 14:00-17:00. "ISO/IEC/IEEE 29148:2018". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  67. ^ 14:00-17:00. "ISO/IEC TR 24766:2009". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  68. ^ 14:00-17:00. "ISO/IEC 25001:2014". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  69. ^ 14:00-17:00. "ISO/IEC 25010:2011". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  70. ^ 14:00-17:00. "ISO/IEC TS 25011:2017". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  71. ^ 14:00-17:00. "ISO/IEC 25012:2008". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  72. ^ 14:00-17:00. "ISO/IEC 25020:2019". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  73. ^ 14:00-17:00. "ISO/IEC 25021:2012". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  74. ^ 14:00-17:00. "ISO/IEC 25022:2016". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  75. ^ 14:00-17:00. "ISO/IEC 25023:2016". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  76. ^ 14:00-17:00. "ISO/IEC 25024:2015". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  77. ^ 14:00-17:00. "ISO/IEC TS 25025:2021". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  78. ^ 14:00-17:00. "ISO/IEC 25030:2019". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  79. ^ 14:00-17:00. "ISO/IEC 25041:2012". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  80. ^ "IEEE Recommended Practice for Software Requirements Specifications". IEEE STD 830-1998: 1–40. October 1998. doi:10.1109/IEEESTD.1998.88286. ISBN 978-0-7381-0448-5.
  81. ^ 14:00-17:00. "ISO/IEC 12119:1994". ISO. Retrieved 2023-01-13. {{cite web}}: |last= has numeric name (help)
  82. ^ "IEEE Standard - Adoption of International Standard ISO/IEC 12119:1994(E) - Information Technology - Software Packages - Quality Requirements and Testing". IEEE Std 1465-1998(R2004) [Adoption of ISO/IEC 12119: 1994(E)]: 1–16. December 1998. doi:10.1109/IEEESTD.1998.4301416. ISBN 978-0-7381-1408-8.
[edit]
  • ("This standard replaces IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 - http://standards.ieee.org/findstds/standard/29148-2011.html")
  • Systems Engineering Body of Knowledge
  • Requirements Engineering Management Handbook by FAA
  • International Requirements Engineering Board (IREB)
  • IBM Rational Resource Library by IEEE Spectrum
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:AndreaArzer/Requirements_engineering&oldid=1135463948"