Jump to content

User:Timdewolff/Requirements Specification

From Wikipedia, the free encyclopedia

Requirements specification is the Requirements Engineering (RE) phase during which elicited requirements are properly documented to form a project guideline.[1] It is the process of meticulously documenting all the system and user requirements. Not to be confused with the document that is created during this process, which is also called requirements specification (or Software requirements specification (SRS) in the field of software development) and is seen as an effective tool for requirements specification, containing a complete description of the behaviour of the system or software to be developed.[2] To produce a quality product, elicited requirements must be clear, complete, comprehensive, and consistent. The requirements can be gathered from various sources, like stakeholders or constraints.

Positioning within RE

[edit]

Requirements engineering is the total process of eliciting individual stakeholder requirements and needs that thereafter are developed into detailed, agreed requirements that are documented and specified in such a way that they can serve as the basis for all other system development activities.[3] Requirements specification is seen as one of the 4 general steps of the RE process.

The requirement engineering process

This process typically features:

Requirements specification is done right after the requirements have been elicited and is (usually) the third step in the process.[4]

Prior to the requirements specification phase, the requirement elicitation takes place. The elicitation phase aims to gather requirements coming from the viewpoints of various stakeholders, constraints, system's operating environment and other perspectives. Requirement elicitation starts with identifying stakeholders. Thereafter, raw requirements can be written down with respect to the importance of these stakeholders. These have not yet been written down well-formed using a requirement notation and will therefore be taken to the requirements specifications phase.[2]

In the requirements specification phase, both functional and non-functional requirements are present as well as constraints that limit these requirements. Designers, developers and project leaders communicate these essential features throughout the entire requirement specification process when developing a system or product. These should be formulated in a uniform and clear manner to smoothen the communication and be able to develop a quality end product.[5] This is done by creating a requirement specification document, featuring use cases that describe interactions between users and the system. Requirements that have been through the specification phase are formulated in such a way that they could be validated by the stakeholders.

History

[edit]

Requirements specification is a step in the Requirements Engineering process. Requirements Engineering is the process of determining requirements in the field of Software Engineering. The field of Software Engineering already dates back a few decades and was originally described by Fritz Bauer at the NATO Software Engineering conference in 1969 as the use of sound engineering principles in order to obtain reliable, economical software that works efficiently on real machines.

At that point in time, the Waterfall model was just introduced.[6] This model proposes a series of successive steps that have to be taken towards the delivery of a software system. The first phase involves understanding what one needs to design together with its function and purpose. Unless one knows what to design, one cannot proceed with the next step of the project. In other words, the requirements which the software is going to satisfy have to be listed, detailed and documented. These requirements are then presented to the team of programmers. If this entire phase is completed successfully, it ensures a smooth working of the remaining phases. This as it was believed to leave the programmer unburdened with the need to make additional changes at later stages because of the requirements agreed upon.[7] This is where Requirements Engineering and Requirement Specification came in and originate from.

In the present, Requirements Engineering is not seen as a series of successive steps but as an iterative process. The requirements specification step is therefore revisited often. Modern belief is that requirements should continuously be updated to make sure it leads to project or product success and customer satisfaction. Customers are therefore also more intensely involved in the creation of these requirements.[8]

Different interpretation in physical context

[edit]

Requirements specification does not only apply to the field of Software engineering. In Software engineering, requirements ascend and change rapidly. Frequently releasing new versions of software products or systems to add, remove or change functionality is common. Requirements therefore have to be managed regularly. This differs in other fields.

Physical products are much less suitable for rapid changes. Requirements of these products are specified before the creation and trade of the product. New requirements or changes do reveal itself after the release. The difference is that releases with the implementation of these does occur less frequent.

Compatible with methods

[edit]

Specifying requirements can be performed using various methods to ensure the uniformity of requirements. This makes these requirements easy to understand and compare for all involved stakeholders. Each of these methods follows different principles and has different goals. Examples of such methods are listed below to give an idea of the kind of methods that can be used for this task. The most well-known method is the User story.

  • Goal modelling: A way of investigating how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests are addressed.
    • KAOS (software development): Stands for Knowledge Acquisition in autOmated Specification or Keep All Objects Satisfied. It is described as a multi-paradigm framework that allows to combine different levels of expression and reasoning.[9]
    • I*: Pronounced as i star. It can be used to understand the problem domain and allows to model both as-is and to-be situations. Can be used in requirements engineering to understand the problem domain. Strategic Dependency models and Strategic Rationale models can then be used to develop use cases.
    • Goal-oriented Requirements Language: An I*-based modeling language designed to support goal-oriented modeling and reasoning about requirements. Especially those classified as a Non-functional requirement.[10] It allows to express conflict between goals and helps to make decisions that resolve conflicts.
  • Use case diagram: A graphical depiction of a user's possible interactions with a system. It shows various use cases and the different types of users that interact with the system.
  • User story: An informal, natural language description of features of a software system. They are written from the perspective of an end user or user that interacts with the system.
  • EARS: Stands for Easy Approach to Requirements Syntax. This is an approach that forces authors to separate the conditions in which the requirement can be invoked (preconditions), the event that initiates the requirement (trigger) and the necessary system behavior (system response) via a small set of simple requirement structures. [11]

Problems

[edit]

Requirements specification also comes with a range of challenges. One of the most difficult challenges in the requirements specification process is to make the requirements detailed enough without adding too much constraints. This to make sure that the requirements can be well understood without predefining and detailing things that can be better left to others downstream the process.[12] The goal is to find the “sweet spot” or the balance point wherein the requirement provides the right amount of specificity and leaves the right amount of ambiguity.

Understandability versus ambiguity trade-off

Another problem is the preservation of understandability for all stakeholders. There is a need to represent certain technical details within requirements to ensure that all system necessities are included and taken care off. This will also result in the use of jargon and technical terms which negatively infect the understandability for stakeholders with less technical knowledge. It is key to optimize the understandability for all stakeholders to make sure all opinions are taken into account.

See also

[edit]

References

[edit]
  1. ^ Firesmith, Donald (April 2003). "Modern Requirements Specification" (PDF). JOURNAL OF OBJECT TECHNOLOGY. Retrieved 6 January 2023.
  2. ^ a b Pandey, Dhirendra; Suman, Ugrasen (October 2010). "An Effective Requirement Engineering Process Model for Software Development and Requirements Management". Retrieved 23 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  3. ^ Pohl, Klaus (23 July 2010). Requirements Engineering: Fundamentals, Principles, and Techniques. Springer Publishing Company, Incorporated. Retrieved 9 January 2023.
  4. ^ Brijesh, Yadav. "Requirement Engineering Process and its uses". MechoMotive. Retrieved 9 January 2023.
  5. ^ Robinson, William N. (March 1990). "Negotiation behavior during requirement specification". Proceedings. 12th International Conference on Software Engineering (pp. 268-276).
  6. ^ Royce, W. W. (1970). "Managing the Development of Large Software Systems" (PDF). Retrieved 9 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  7. ^ McCormick, Mike (8 September 2012). "Waterfall vs. Agile Methodology" (PDF). Retrieved 9 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  8. ^ Wagner, Stefan; Fernandez, Daniel; Felderer, Michael; Vetro, Antonio; Kalinowski, Markos; Wieringa, Roel; Pfahl, Dietmal; Conte, Tayana; Christiansson, Marie-Therese; Greer, Desmond; Lassenius, Casper; Mannisto, Tomi; Nayebi, Maleknaz; Oivo, Markku; Penzenstadler, Birgit (February 2019). "Status Quo in Requirements Engineering: A Theory and a Global Family of Surveys". Retrieved 23 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  9. ^ Lapouchnian, Alexei (28 June 2005). "Goal-Oriented Requirements Engineering: An Overview of the Current Research" (PDF). Retrieved 23 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  10. ^ Weiss, Michael; Amyot, Daniel (January 2005). "Designing and Evolving Business Models with URN". Retrieved 23 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  11. ^ Mavin, Alistair; Wilkinson, Philip; Harwood, Adrian; Novak, Mark (31 August 2009). "Easy Approach to Requirements Syntax (EARS)". Retrieved 23 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
  12. ^ Wahono, Romi Satria (2003). "ANALYZING REQUIREMENTS ENGINEERING PROBLEMS" (PDF). Retrieved 9 January 2023. {{cite journal}}: Cite journal requires |journal= (help)
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Timdewolff/Requirements_Specification&oldid=1135387552"