Requirements Document

A Requirements Document is a specification document that describes the system requirements of a designed system.

• Context:
  • It can be produced by a Requirements Analysis Task.
  • It can be managed by a Requirements Management System.
  • ...
• Example(s):
  • Business Requirements Document, Software Requirements Specification Document.
  • Product Requirements Document, for product requirements.
  • Functional Requirements Document, for functional requirements.
  • …
• Counter-Example(s):
  • a System Design Document.
  • a Business Process Model.
  • a Technical Specifications Document.
• See: System Design Document, Business User, Business Process Owner, Ontology, Software Development Methodology.

---

---

References

• Requirements Engineering Journal http://www.springer.com/computer/swe/journal/766
• IEEE Transactions on Software Engineering and the Requirements Engineering Journal.
• IEEE International Requirements Engineering Conference http://www.requirements-engineering.org/
• International Conference on Software Engineering http://www.icse-conferences.org/

2011

• http://en.wikipedia.org/wiki/Requirements_management
  • Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform. ... The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these.

2010

• (Körner & Landhäußer, 2010) ⇒ Sven J. Körner, and Mathias Landhäußer. (2010). “Semantic Enriching of Natural Language Texts with Automatic Thematic Role Annotation.” In: Proceedings of the 15th International Conferefence on Applications of Natural Language to Information Systems (NLDB 2010). doi:10.1007/978-3-642-13881-2_9
  • … Requirements documents include the syntax of natural language but not the semantics.

2008

• (Melli & McQuinn, 2008) ⇒ Gabor Melli, and Jerre McQuinn. (2008). “Requirements Specification Using Fact-Oriented Modeling: A Case Study and Generalization.” In: Proceedings of Workshop on Object-Role Modeling (ORM 2008). doi:10.1007/978-3-540-88875-8_98
  • QUOTE: ... The approach however has not yet been fully incorporated into software requirement specification standards [8], [9], [10], [12], [13], [14], [2]. With the introduction of such standards as Structured Business Vocabulary and Rules (SBVR) [5], [7] it is now possible to consistently employ Fact-oriented Modeling in the delivery of enterprise solutions.

2006

• (Kaiya & Saeki, 2006) ⇒ Haruhiko Kaiya, and Motoshi Saeki. (2006). “Using Domain Ontology as Domain Knowledge for Requirements Elicitation.” In: Proceedings of the 14th IEEE International Requirements Engineering Conference (RE 2006). doi:10.1109/RE.2006.72

2007

• (Cheng & Atlee, 2007) ⇒ Betty H. C. Cheng, and Joanne M. Atlee. (2007). “Research Directions in Requirements Engineering.” In: Proceedings Future of Software Engineering (FOSE 2007).
  • ABSTRACT: In this paper, we review current requirements engineering (RE) research and identify future research directions suggested by emerging software needs. First, we overview the state of the art in RE research. The research is considered with respect to technologies developed to address specific requirements tasks, such as elicitation, modeling, and analysis. Such a review enables us to identify mature areas of research, as well as areas that warrant further investigation. Next, we review several strategies for performing and extending RE research results, to help delineate the scope of future research directions. Finally, we highlight what we consider to be the "hot" current and future research topics, which aim to address RE needs for emerging systems of the future.
  • QUOTE: The success of a software system depends on how well it fits the needs of its users and its environment [127, 130]. Software requirements comprise these needs, and requirements engineering (RE) is the process by which the requirements are determined. Successful RE involves understanding the needs of users, customers, and other stakeholders; understanding the contexts in which the to-be-developed software will be used; modeling, analyzing, negotiating, and documenting the stakeholders’ requirements; validating that the documented requirements match the negotiated requirements; and managing requirements evolution. (In addition, there are a number of software-engineering activities that are based on requirements information, such as cost estimation, project planning, and requirements-based derivations of architectures, designs, code, and test cases. Although these activities are “related” to a system’s requirements, they play at most a minor role in determining and agreeing on the system’s requirements; as such, we consider them to be outside the scope of requirements engineering.)

2003

• (Maedche et al., 2003) ⇒ Alexander Maedche, Boris Motik, and Ljiljana Stojanovic, Rudi Studer, and Raphael Volz. (2003). “Ontologies for Enterprise Knowledge Management.” In: IEEE Intelligent Systems, 18(2). doi:10.1109/MIS.2003.1193654

2002

• (Castro et al., 2002) ⇒ Jaelson Castro, Manuel Kolp, and John Mylopoulos. (2002). “Towards requirements-driven information systems engineering: the Tropos project.” In: Inf. Syst. 27(6). doi:10.1016/S0306-4379(02)00012-1
  • ~526 http://scholar.google.com/scholar?q=%22Towards+requirements-driven+information+systems+engineering%3A+the+Tropos+project%22+2002
  • ABSTRACT: Information systems of the future will have to perform well within ever-changing organizational environments. Unfortunately, existing software development methodologies (object-oriented, structured or otherwise) have traditionally been inspired by programming concepts, not organizational ones, leading to a semantic gap between the software system and its operational environment. To reduce this gap, we propose a software development methodology named Tropos which is founded on concepts used to model early requirements. Our proposal adopts the [math]\displaystyle{ i }[/math] organizational modeling framework, which offers the notions of actor, goal and (actor) dependency, and uses these as a foundation to model early and late requirements, architectural and detailed design. The paper outlines Tropos phases through an e-business example, and sketches a formal language which underlies the methodology and is intended to support formal analysis. The methodology seems to complement well proposals for agent-oriented programming platforms.

1976

• (Bell & Thayer, 1976) ⇒ T. E. Bell and T. A. Thayer. 1976. “Software requirements: Are they really a problem?.” In: Proceedings of the 2nd International Conference on Software engineering (ICSE 1976).
  • QUOTE: ... The Military Standard set MIL- STD 490/483 recognized this newer approach by specifying a system requirements document, a "design-to" requirements document that is created in response to the system requirements, and then a "code-to" requirements document for each ...

---