Software Requirements Documentation PDF

Software Requirements Documentation  Reason for the documentation Requirements are the basis of the system development. Requirements have a legal relevance. Requirements are (may be) complex. Requirements must be accessible to all involved parties.  Using Requirement Doc...

Software Requirements Documentation  Reason for the documentation Requirements are the basis of the system development. Requirements have a legal relevance. Requirements are (may be) complex. Requirements must be accessible to all involved parties.  Using Requirement Documents Requirements documents serve as the basis for different tasks, over the course of the project, : Planning Architectural Design Implementation Test Change Management System usage and maintenance Contract management  Data → The structure and flow of input and output data Data Functional → The processes that run on the Three system and how they interact Perspective with each other (proces flow) Functional Requirement Behavioral → The reaction of the system upon the event, the condition, and the effect that the system shall have on its Behavioral environment  Types of Documentation Requirement Documentation using Requirement Documentation using Natural Language Conceptual Model Most commonly applied in practice cannot be used universally No notation special modeling languages must be Express any kind of requirement used that pertain to the appropriate Requirements can be ambiguous perspective and unintentionally mixed up depict information more compactly Difficult to isolate information and decreased degree of ambiguity easier for a trained reader to understand than is natural language  Conceptual Model Overview of system Use Case Diagram function DFD Structural Data Class Diagram Modeling ER Diagram Activity Diagram Sequence Modeling Flow Chart Diagram Sequence Diagram Event-Driven Behavior State Diagram  Quality Criteria for Requirement Documentation According to the ISO/IEC/IEEE standard 29148:2011 [ISO/IEC/IEEE 29148:2011], a requirements document shall be: Unambiguity and consistency Clear structure Modifiability and extendibility Completeness Traceability  Quality criteria for single document Requirements Quality Criteria Desc Short sentences & As human short-term memory is very limited, circumstances that belong together should be short paragrafs described in no more than seven sentences. Formulate only Formulate requirements using active voice and use only one process verb. Long, complicated one requirement interlaced sentences must be avoided. per sentence Agreed A requirement is agreed upon if it is correct and necessary in the opinion of all stakeholders Unambigous can be understood in only one way. It must not be possible to interpret the requirement in a different way. Necessary A documented requirement must represent the facts and conditions of the system context in a way  Quality criteria for single document Requirements Quality Criteria Desc Complete Each individual requirement must completely describe the functionality it specifies Understandable Requirements must be comprehensible to each stakeholder. Feasible It must be possible to implement each requirement given the organizational, legal, technical, or financial constraints. Traceable A requirement is traceable if its origin as well as its realization and its relation to other documents can be retraced. Consistent the requirements must not contradict one another, regardless of their level of detail or documentation type. Verifiable A requirement must be described in a way that allows for verification. Document Structure Standardized Document Structure RUP ISO/IEC/IEEE standard 29148:2011 V-Model Customized Standard Contents (Minimum Content) (1) Introduction (3) Requirement (5) Index (2) General (4) Appendices Overview  Introduction Purpose: This section discusses why the document was created and who the target audience for the requirements document is. System coverage: This part consists of the system to be developed. It indicates system name and the principle goals and advantages that arise from introducing the system. Stakeholder: This section contains a list of stakeholders and their relevant information Definitions, Acronyms, and Abbreviations: The terms used in the document are defined so that they can be used consistently throughout the document. References: All documents that are referenced by the requirements document are listed herein. Overview: At the end of the introductory chapter, the content and structure of the following sections of the requirements document should be explained briefly.  General Overview System environment: The embedding of the system into the environment is of key concern in this paragraph. The results of your definition of the system boundary and context boundary can be found herein. Architecture description: The operational interfaces of the system (e.g., user interfaces, hardware and software interfaces, and communication interfaces) are documented. In ddition, further information, e.g., regarding storage limitations, is also discussed. System functionality: This section contains the coarse functionalities and tasks of the system. This can be documented, for example, using a use case diagram. User and target audience: The different users of the system that make up the target audience are listed. Constraints: In this section, all conditions ought to be listed that have not been documented thus far and might hinder the requirements engineering. Assumptions: Decisions, such as not implementing certain aspects of the system due to budgeting reasons, or other general assumptions about the system context that the requirements are based upon are documented here  Requirements This part contains Non functional requirements as well as quality requirements.  Appendices In the appendices, additional information that completes the document can be documented. For example, the appendices can include additional documents regarding the user characteristics, standards, conventions, or background information regarding the requirements document.  Index The index typically contains a table of contents (i.e., a structure of the chapters) and an index directory. In highly dynamic requirements documents, this may be a highly critical section that must be kept up- to-date. Thank You  Reference Requirements Engineering Fundamentals. Klaus Pohl, Chris Rupp. 2015