EO 4.1.1
key reasons for requirements documentation
Documentation plays a goal-orientated supporting function in communication. The following factors make this support necessary. Requirements are long-lasting, legally relevant and should be accessible to all. Requirements documents are complex.
EO 4.2.1
The three perspectives of functional requirements
Data perspective
Behavioral perspective
Functional perspective
EO 4.2.2: 1/2
Knowing advantages of natural language requirements documentation
Advantages of natural language
- No stakeholder has to learn a new notation.
- The language can be used for miscellaneous purposes 3. The requirements engineer can use natural language to express any kind of requirement.
EO 4.2.2: 2/2
Knowing disadvantages of natural language requirements documentation
Disadvantages of natural language
- natural language can allow requirements to be ambiguous
- requirements of different types and perspectives are in danger of being unintentionally mixed up during documentation.
- In that case, it is difficult to isolate information pertaining to a certain perspective amidst all of the requirements in natural language.
EO 4.2.3: the most important model-based requirements documentation form 1. System function 2. Structural data modeling 3. Sequence modeling 4. Event driven behavior
- System function: use case diagram
- Structural data modeling: Class diagram
- Sequence modeling: Activity diagram
- Event driven behavior: State diagram
EO 4.2.4:
the advantages of mixed form of requirements documentation
“The combination allows the disadvantages of both documentation types to be decreased by means of the strengths of the other documentation type, and combining documentation types exploits the advantages of both. For instance, models can be amended or complemented by natural language comments and natural language requirements and natural language glossaries can be summarized and their dependencies can be depicted clearly by making use of models.”
EO 4.3.1
the advantages of standardized document structures
- Standard outlines simplify incorporating new staff members.
- Standard outlines allow for quickly finding desired contents.
- Standard outlines allow for selective reading and validation of requirements documents.
- Standard outlines allow for automatic verification of requirements documents (e.g., with regard to completeness).
- Standard outlines allow for simplified reuse of the contents of requirements documents.
EO 4.3.2
The 3 widespread document structures
- Rational united process (RUP)
- IEEE standrad
- V model
EO 4.3.3
important points for a tailored standard structure
- Introduction:
- propose 2. System coverage 3. Stakeholders 4. Definitions, abbreviations 5. references 6. overview
- General overview:
- System environment 2. architecture description 3. System functionality 4. users and target audience 5. constrains 6. Assumptions
- Requirements
- Appendices
- Index
EO 4.5:
quality criteria for requirements documents
- Unambiguity and Consistency Requirements documents can be consistent and unambiguous only when the individual requirements are consistent and unambiguous. In addition, it must be guaranteed that individual requirements do not contradict one another.
- Clear Structure In order to guarantee that the requirements document is readable by any stakeholder, it should be appropriately comprehensive and clearly structured.
- Modifiability and Extendibility Requirements documents must be easy to extend. There are always requirements that are changed, altered, added, or removed as a project progresses.
- Completeness Requirements documents must be complete, i.e., they must contain all relevant requirements (and required additional information), and each requirement must be documented completely.
- Traceability An important quality criterion is traceability of relationships between requirements documents and other documents (e.g., business process model, test plans, or design plans).
EO 4.4.1
uses requirements documents
Planning
Architectural design
Implementation
Test
Change management
System usage and system maintenance
Contract management
EO 4.6.1
quality criteria for requirements (single requirement)
agreed
unambiguous
necessary
consistent
verifiable
feasible
traceable
complete
understandable
EO 4.7.1
contents and importance of glossary
A frequent cause of conflicts, arising in RE, lies in the different understanding of terminology among the involved people. To prevent this problem, it is necessary that all relevant terms are defined in a glossary. A glossary is a collection of term definitions for:
- context-specific technical terms
- abbreviations and acronyms
- everyday concepts that have a special meaning in the given context
- synonyms
- homonyms
EO 4.7.2
the rules fire handing the glossary
The glossary must be managed centrally
The responsibilities for maintaining the glossary must be defined
The glossary must be maintained over the course of the project
The glossary must be commonly accessible
Use of the glossary must be obligatory
The glossary should contain the sources of the terms
The stakeholders should agree upon the glossary
The entries in the glossary should have a consistent structure
