5. Requirements Engineering Flashcards
Requirements (Requirements Definition, Design Definition)
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.
User Requirements (Characteristics (3))
- statements in natural language
- supported by diagrams of the services the system provides and its operational constraints
- written for customers
System Requirements (Characteristics (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
Functional Requirements (Characteristics (4))
- define the provided service
- describe the systems functionalities
- describe the system behavior
- describe the system reactions
Non-Functional Requirements (Characteristics (2))
- specification of quality of service
- constraints on the services (e.g. timing constraints, fault tolerance exception handling,..)
Categories of Non-Functional Requirements (5)
- Usability = defines how the behavior of the system must be shaped to dit the users and their work environment
- Reliability = defines the dependability of the system both in time and in the fulfillment of its functions (e.g. mean time between failures)
- Performance = specifies the response time and the input-output volume that the system can handle within a particular time frame
- Maintainability = specifies the ability of the system to be modified and enhanced.
- Security = specifies the access rights and tracing of interactions (e.g. event logging)
Measuring Non-Functional Requirements (5 Measures)
- Speed (Processed transactions, event response time)
- Size (Mbytes, number of ROM chips)
- Ease of Use (Training time, number of support features)
- Reliability (Rate of failure occurrence)
- Robustness (Time to restart after failure)
Requirements Engineering (State, Characteristics (4))
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
Key Requirements Engineering Tasks (4)
- Requirements Elicitation
- discovers all facets of requirements
- involves all the relevant stakeholders of the project
- Requirements specification
- classifies and organizes requirements
- prioritizes and negotiates
- covers functional and technical analysis
- Requirements Validation
- checks if the requirement actually define what
customers really want
- checks if the requirement actually define what
- Requirements Management
- documents history of accepting new requirements
- changes or drops existing requirements
- traces requirements implementation
Requirements Elicitation (4 Characteristics)
- 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
Problems of Elicitation (7)
- 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
Sources of Requirements (2)
- People
- Sponsors
- Domain Experts- Users
- Other Stakeholders:
- 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.
- Legacy System: already existing systems the new
Requirements Specification (3)
- Requirements classification and organization = groups related requirements and organize them into coherent clusters
- Prioritization and negotiation = prioritizing requirements and resolving requirements conflicts
- Requirements specification = requirements are documented and input into the next round of the spiral
The Requirement Document (Purpose/Characteristics)
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
Users of Requirements Document (5)
- 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)
- Managers = Use requirements documents to plan a bid for the system and to plan the development process.
- System Engineers = use the requirements to understand what system is to be developed
- System Test Engineers = use the requirements to develop validation tests for the system
- System Maintenance Engineers = Use the requirements to understand the system and the relationship between its parts
Keys for precisely describing a software requirement (3)
- Precision = Ambiguous requirements may be interpreted in different ways by developers and users
- Completeness = They should include the full set of requirements
- 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
Prioritization of Requirements (2 Types of prioritized Requirements)
- Mandatory Requirements
- fulfilling business need
- not implementing results in a loss of customers and
revenue - drastic impact on business value
- Optional Requirements
- less degree of urgency
- implementing may result in additional business
benefits - can turn into a mandatory one
Requirements Validation (3 Steps)
- 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
- communication with developers, customers, and
- 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 - 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
Requirements Management (Definition, Importance, Tasks (4))
= “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
Three Perspectives on Managing Requirements
- Customer Orientation = Customers have requirements in order to get to their problem -> Customer RM ensures that costumer requirements are recognized and implemented in products.
- 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.
- 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.
Management Requirements: Traceability (2 Keys for Development in Practice)
“In practice, it often is important to know the source of the requirement and to ensure that it was tested”
- Traceability = the source of each requirement is identified and linked back to the original customer requirement that was elicitated.
- Testable = defines that within one requirement there are no contradicting aspects, which makes the requirement per se not testable.
What should the RD contain? (4)
It should contain:
- Introduction to document
- description of function and functionality
- listed requirements
- appendices, glossary, references, index
