5. Requirements Engineering

Question 1

Requirements (Requirements Definition, Design Definition)

Answer 1

Requirements = should state what the system should do and what characteristics it should exhibit to perform the predefined tasks required by end-users

Design = should describe how the system does this

=> the system’s architecture is designed to structure the requirements.

Question 2

User Requirements (Characteristics (3))

Answer 2

• statements in natural language
• supported by diagrams of the services the system provides and its operational constraints
• written for customers

Question 3

System Requirements (Characteristics (3))

Answer 3

• structured document setting out detailed descriptions of the system’s functions
• defines what should be implemented
• can be part of contract between client and contractor

Question 4

Functional Requirements (Characteristics (4))

Answer 4

• define the provided service
• describe the systems functionalities
• describe the system behavior
• describe the system reactions

Question 5

Non-Functional Requirements (Characteristics (2))

Answer 5

• specification of quality of service

- constraints on the services (e.g. timing constraints, fault tolerance exception handling,..)

Question 6

Categories of Non-Functional Requirements (5)

Answer 6

1. Usability = defines how the behavior of the system must be shaped to dit the users and their work environment
2. Reliability = defines the dependability of the system both in time and in the fulfillment of its functions (e.g. mean time between failures)
3. Performance = specifies the response time and the input-output volume that the system can handle within a particular time frame
4. Maintainability = specifies the ability of the system to be modified and enhanced.
5. Security = specifies the access rights and tracing of interactions (e.g. event logging)

Question 7

Measuring Non-Functional Requirements (5 Measures)

Answer 7

1. Speed (Processed transactions, event response time)
2. Size (Mbytes, number of ROM chips)
3. Ease of Use (Training time, number of support features)
4. Reliability (Rate of failure occurrence)
5. Robustness (Time to restart after failure)

Question 8

Requirements Engineering (State, Characteristics (4))

Answer 8

Requirements Engineering is a continuous process.

• Requirements are often not fully comprehensive from beginning on
• Not all requirements are equally important
• Requirements can change
• Different stakeholders have different requirements

Question 9

Key Requirements Engineering Tasks (4)

Answer 9

1. Requirements Elicitation
   
   • discovers all facets of requirements
   • involves all the relevant stakeholders of the project
2. Requirements specification
   
   • classifies and organizes requirements
   • prioritizes and negotiates
   • covers functional and technical analysis
3. Requirements Validation
   
   • checks if the requirement actually define what
     customers really want
4. Requirements Management
   
   • documents history of accepting new requirements
   • changes or drops existing requirements
   • traces requirements implementation

Question 10

Requirements Elicitation (4 Characteristics)

Answer 10

• elicitation allows the development team to dig for the customers’ requirements underlying the solution the be developed
• successful projects reflect requirements that are derived from a variety of sources
• elicitation provides grounds to systematically organize, synthesize, and rationalize the data
• rationalizing helps tp reduce the number of requirements that may be in conflict or redundant

Question 11

Problems of Elicitation (7)

Answer 11

• Stakeholders often don’t know what they really want
• Stakeholder express requirements in their own terms
• Different stakeholders may have conflicting requirements
• The requirements change during the analysis process
• New stakeholders emerge
• The business environment may change

Question 12

Sources of Requirements (2)

Answer 12

1. People
   - Sponsors
   - Domain Experts
   
   • Users
   • Other Stakeholders:
2. Reverse Engineering
   
   • Legacy System: already existing systems the new
     system has to be adopted to or integrated with
   • Existing document: like guidelines, process
     descriptions, manuals, etc.

Question 13

Requirements Specification (3)

Answer 13

1. Requirements classification and organization = groups related requirements and organize them into coherent clusters
2. Prioritization and negotiation = prioritizing requirements and resolving requirements conflicts
3. Requirements specification = requirements are documented and input into the next round of the spiral

Question 14

The Requirement Document (Purpose/Characteristics)

Answer 14

The requirement document is
- the official statement of what the development
team needs to implement
- explains why a product is needed
- puts the product in context
- describes what the finished product will be like
- important input to validate requirements
- guides to development and testing

Question 15

Users of Requirements Document (5)

Answer 15

1. System Customers = specify the requirements and read them to check that they meet their needs (can be used interchangeably: business, project or system sponsors, also managers)
2. Managers = Use requirements documents to plan a bid for the system and to plan the development process.
3. System Engineers = use the requirements to understand what system is to be developed
4. System Test Engineers = use the requirements to develop validation tests for the system
5. System Maintenance Engineers = Use the requirements to understand the system and the relationship between its parts

Question 16

Keys for precisely describing a software requirement (3)

Answer 16

1. Precision = Ambiguous requirements may be interpreted in different ways by developers and users
2. Completeness = They should include the full set of requirements
3. Consistence = There should be no conflicts or contradictions in the descriptions of the systems facilities

=> only experienced requirements engineers are capable of writing very precise requirements documents

Question 17

Prioritization of Requirements (2 Types of prioritized Requirements)

Answer 17

1. Mandatory Requirements
   
   • fulfilling business need
   • not implementing results in a loss of customers and
     revenue
   • drastic impact on business value
2. Optional Requirements
   
   • less degree of urgency
   • implementing may result in additional business
     benefits
   • can turn into a mandatory one

Question 18

Requirements Validation (3 Steps)

Answer 18

1. Requirement Reviews
   - systematic manual analysis
   - regular reviews during requirements definition
   - both client and contractor staff should be involved
   - reviews may be formal (w/ completed documents) or
   informal
   
   • communication with developers, customers, and
     users can avoid problems early
2. Early Test Case Development
   - start early with developing test cases -> to visualize
   what the system might look like
   - having test cases already in requirement
   specification can help to prevent future problems
   - test conditions and expected results need to be
   specified
3. Rapid Prototyping
   - development of an early, rudimentary version of a
   system
   - includes essential features
   - assists when requirements are poorly understood
   - enable stakeholder to get experience
   - promotes discussion of unidentified features
   - common point of reference

Question 19

Requirements Management (Definition, Importance, Tasks (4))

Answer 19

= “process of identifying, eliciting, documenting, analyzing, tracing, prioritizing, validating, and agreeing on requirements and then controlling implementation and change as well as communication with relevant stakeholders”
=> once the requirement is validated, it’s essential for the entire project!

Management’s tasks are to:
- catalog, store, and manage requirements throughout
the entire project
- manage changing requirements during the
requirements engineering process and system
development
- keeps track of individual requirements and maintains
links between different requirements

Question 20

Three Perspectives on Managing Requirements

Answer 20

1. Customer Orientation = Customers have requirements in order to get to their problem -> Customer RM ensures that costumer requirements are recognized and implemented in products.
2. Product Orientation = Products provide solution to the customer problems in the corresponding requirements -> Product RM ensures sustainability and profitability of development by defining, prioritizing, and mapping product requirements from diverse sources.
3. Project Orientation = New software is developed in projects with well-defined contents and schedules addressing product requirements -> Project RM analyzes and details product requirements and ensures implementation within project boundaries.

Question 21

Management Requirements: Traceability (2 Keys for Development in Practice)

Answer 21

“In practice, it often is important to know the source of the requirement and to ensure that it was tested”

1. Traceability = the source of each requirement is identified and linked back to the original customer requirement that was elicitated.
2. Testable = defines that within one requirement there are no contradicting aspects, which makes the requirement per se not testable.

Question 22

What should the RD contain? (4)

Answer 22

It should contain:

• Introduction to document
• description of function and functionality
• listed requirements
• appendices, glossary, references, index