Jump to content

Requirements engineering

From Wikipedia, the free encyclopedia

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

Requirements management, which is a branch of systems engineering, is also indexed in the International Council on Systems Engineering (INCOSE) manuals.

Activities

[edit]

The activities involved in requirements engineering vary widely, depending on the type of system being developed and the organization's specific practice(s) involved.[2] These may include:

  1. Requirements elicitation – Developers and stakeholders meet; the latter are inquired concerning their needs and wants regarding the software product.
  2. Requirements analysis and negotiation – Requirements are identified (including new ones if the development is iterative), and conflicts with stakeholders are solved. Both written and graphical tools (the latter commonly used in the design phase, but some find them helpful at this stage, too) are successfully used as aids. Examples of written analysis tools: use cases and user stories. Examples of graphical tools: Unified Modeling Language (UML).[3]
  3. System modeling – Some engineering fields (or specific situations) require the product to be completely designed and modeled before its construction or fabrication starts. Therefore, the design phase must be performed in advance. For instance, blueprints for a building must be elaborated before any contract can be approved and signed. The system might be designed using UML.
  4. Requirements specification – Requirements are documented in a formal artifact called a Requirements Specification (RS), which will become official only after validation. A RS can contain both written and graphical (models) information if necessary. Example: Software requirements specification (SRS).
  5. Requirements validation – Checking that the documented requirements and models are consistent and meet the stakeholder's needs. Only if the final draft passes the validation process, the RS becomes official.
  6. Requirements management – Managing all the activities related to the requirements since inception, supervising as the system is developed, and even until after it is put into use (e. g., changes, extensions, etc.)

These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities.

Requirements engineering has been shown to clearly contribute to software project successes.[4]

Issues

[edit]

One limited study in Germany presented possible problems in implementing requirements engineering and asked respondents whether they agreed that they were actual problems. The results were not presented as being generalizable but suggested that the principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities.[5]

Problem structuring, a key aspect of requirements engineering, has been speculated to reduce design performance.[6] Some research suggests that it is possible if there are deficiencies in the requirements engineering process resulting in a situation where requirements do not exist, software requirements may be created regardless as an illusion misrepresenting design decisions as requirements [7]

See also

[edit]

References

[edit]
  1. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF). International Conference on Software Engineering (ICSE) '87. Proceedings of the 9th international conference on Software Engineering. pp. 1–9.
  2. ↑ Sommerville, Ian (2009). Software Engineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
  3. ↑ "Uncovering Requirements With UML Class Diagrams Part 1". tynerblain.com. March 7, 2008. Retrieved March 14, 2018.
  4. ↑ Hofmann, H. F.; Lehner, F. (2001). "Requirements engineering as a success factor in software projects". IEEE Software. 18 (4): 58–66. Bibcode:2001ISoft..18d..58H. doi:10.1109/MS.2001.936219.
  5. ↑ Méndez Fernández, Daniel; Wagner, Stefan (2015). "Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany". Information and Software Technology. 57: 616–643. arXiv:1611.04976. doi:10.1016/j.infsof.2014.05.008. S2CID 1924926.
  6. ↑ Ralph, Paul; Mohanani, Rahul (May 2015). Is Requirements Engineering Inherently Counterproductive?. 2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks). IEEE. doi:10.13140/2.1.3831.6321.
  7. ↑ Ralph, P. (September 2013). "The illusion of requirements in software development". Requirements Engineering. 18 (3): 293–296. arXiv:1304.0116. Bibcode:2013AIPC.1516..293R. doi:10.1007/s00766-012-0161-4. S2CID 11499083.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Requirements_engineering&oldid=1382064719"