System Requirement Specification Document

A System Requirement Specification Document is a formal technical Requirement Specification that comprehensively defines system requirements, functional requirements, and constraints.

• AKA: Requirement Specification Report, System Requirements Specification, SRS, Requirements Specification Document.
• Context:
  • It can typically contain Requirement Specification Statements through organized requirement sections and structured requirement lists.
  • It can typically organize Requirement Categorys through functional requirement sections and non-functional requirement sections.
  • It can typically establish Requirement Hierarchys through requirement decompositions and requirement relationships.
  • It can typically ensure Requirement Completeness through requirement coverage analysises and gap identifications.
  • It can typically maintain Requirement Consistency through cross-requirement validations and conflict resolutions.
  • It can typically provide Requirement Context through background informations and stakeholder perspectives.
  • It can typically support Requirement Approval through formal review processes and sign-off procedures.
  • ...
  • It can often include Requirement Metadata through requirement identifiers and requirement attributes.
  • It can often incorporate Requirement Rationales through justification statements and business cases.
  • It can often define Acceptance Criteria through verification methods and validation procedures.
  • It can often establish Requirement Baselines through version controls and change managements.
  • It can often support Multi-Stakeholder Views through role-based sections and audience-specific contents.
  • ...
  • It can range from being a Brief Requirement Specification Document to being a Comprehensive Requirement Specification Document, depending on its requirement document scope.
  • It can range from being a High-Level Requirement Specification Document to being a Detailed Requirement Specification Document, depending on its requirement document granularity.
  • It can range from being a Static Requirement Specification Document to being a Living Requirement Specification Document, depending on its requirement document maintenance approach.
  • It can range from being a Traditional Requirement Specification Document to being a Agile Requirement Specification Document, depending on its requirement document methodology.
  • It can range from being a Text-Based Requirement Specification Document to being a Model-Based Requirement Specification Document, depending on its requirement document format.
  • ...
  • It can integrate with Project Management Systems for requirement tracking and progress monitoring.
  • It can connect to Design Documents for requirement traceability and design validation.
  • It can interface with Test Plans for test coverage and requirement verification.
  • It can communicate with Change Control Boards for requirement change and impact assessment.
  • It can synchronize with Configuration Management Systems for version control and baseline management.
  • ...
• Example(s):
  • Technology-Specific System Requirement Specification Documents defining system-wide requirements, such as:
    • Software System Requirement Specification Documents for software development projects.
    • Hardware System Requirement Specification Documents for hardware engineering projects.
    • Embedded System Requirement Specification Documents for integrated system projects.
  • Product Requirement Specification Documents capturing product needs, such as:
    • Consumer Product Requirement Specification Documents for market-driven products.
    • Industrial Product Requirement Specification Documents for business equipments.
    • Medical Device Requirement Specification Documents for healthcare products.
  • Service Requirement Specification Documents establishing service standards, such as:
    • IT Service Requirement Specification Documents for technology services.
    • Business Service Requirement Specification Documents for operational services.
    • Cloud Service Requirement Specification Documents for platform services.
  • Domain-Specific Requirement Specification Documents for specialized contexts, such as:
    • Aerospace Requirement Specification Documents meeting aviation standards.
    • Automotive Requirement Specification Documents following vehicle regulations.
    • Financial System Requirement Specification Documents ensuring compliance requirements.
  • ...
• Counter-Example(s):
  • Requirement Specification Statements, which are individual requirements rather than complete documents.
  • Design Documents, which specify solution architectures rather than requirement collections.
  • User Manuals, which provide usage instructions rather than requirement definitions.
  • Test Specifications, which define verification procedures rather than requirement statements.
• See: Requirement Specification, Requirement Specification Statement, Software Design Document, System Design Document, Technical Document, Requirement Engineering Process, Requirement Management System.

---

---

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 ...

---