ITP54: Requirements Engineering
Studied by 0 people
Call with Kai
Knowt Play
Learn
Practice Test
Spaced Repetition
Match
Flashcards1/109
There's no tags or description
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced |
|---|
No study sessions yet.
110 Terms
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
Requirements Engineering
The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process
Requirements Engineering
a high-level abstract statement of a service or of a system constraint
Requirement
Written in natural language plus diagrams.
User requirements
Describe what the system should do and its operational constraints.
User requirements
Written for customers
User requirements
A structured, detailed document describing system functions, services, and constraints.
System requirements
Defines what should be implemented
System requirements
statements of services the system should provide
Functional requirements
how the system should react to particular inputs and how the system should behave in particular situations.
Functional requirements
May state what the system should not do
Functional requirements
Describe functionality or system services.
Functional requirements
Depend on:
The type of software being developed.
The expected users.
The type of system where the software is used.
Functional Requirements
user requirements may be high-level statements of what the system should do.
functional requirements
should describe the system services in detail
Functional Requirements
Problems arise when requirements are not precisely stated.
Requirements imprecision
leads to different interpretations between developers and users.
Ambiguous
They should include descriptions of all facilities required
Complete
There should be no conflicts or contradictions in the descriptions of the system facilities.
Consistent
They are constraints on services or functions.
Non-functional requirements
They apply to the system as a whole rather than to specific features.
Non-functional requirements
Define system properties and constraints
Non-functional requirements
Might require a specific IDE, programming language, or development method.
Process requirements
can be more critical than functional requirements.
Non-functional requirements
the system may be useless — even if all functional requirements are satisfied.
Non-functional requirements
affect the overall system architecture rather than individual components.
non-functional requirements
may generate a number of related functional requirements that define system services that are required.
security requirements
It may also generate requirements that restrict existing requirements.
security requirements
which specify that the delivered product must behave in a particular way
Product requirements
which are a consequence of organizational policies and procedures
Organizational Requirements
which arise from factors which are external to the system and its development process
External requirements
A general intention of the user such as ease of use.
non functional requirements
Constraints on the system from the domain of operation
Domain Requirements
The system’s operational domain imposes requirements on the system.
Domain requirements
If not satisfied, the system may become unworkable.
Domain requirements
Requirements are expressed in the language of the application domain
Understandability
Often not understood by software engineers.
Understandability
Domain specialists understand the area so well that they do not think of making the domain requirements explicit
Implicitness
is an iterative activity in which these processes are interleaved
RE
Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
Requirements Elicitation and Analysis
May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions
Requirements Elicitation and Analysis
Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage
Requirements discovery
Groups related requirements and organizes them into coherent clusters
Requirements classification and organization
Prioritizing requirements and resolving requirements conflicts.
Prioritization and negotiation
Requirements are documented and input into the next round of the spiral
Requirements specification
The process of gathering information about required and existing systems, then identifying user and system requirements.
Requirements Discovery
Involves interaction with stakeholders
Requirements Discovery
The process of writing don the user and system requirements in a requirements document
requirements specification
More detailed requirements that may include technical information.
Requirements Specification
Can be part of a contract for system development.
Requirements Specification
Must be as complete as possible to avoid issues later.
Requirements Specification
Written in plain sentences, usually numbered.
Natural Language
Uses templates/forms.
Structured Natural Language
Each field describes an aspect of the requirement.
Structured Natural Language
Uses programming-like languages
Design Description Languages
Defines operational models.
Design Description Languages
Rarely used, but useful for interface specifications
Design Description Languages
Uses diagrams + text annotations.
Graphical Notations
Based on math concepts
Mathematical Specifications
Removes ambiguity but hard for customers to understand.
Mathematical Specifications
Rarely accepted as contracts.
Mathematical Specifications
state what the system should do.
Requirements
describes how the system does it.
Design
Requirements written in plain sentences, often supported by diagrams and tables.
Natural Language Specification
Used for writing requirements because it is expressive, intuitive and universal.
natural language specification
Precision is difficult without making the document difficult to read
Lack of clarity
Functional and non-functional requirements tend to be mixed-up
Requirements confusion
Several different requirements may be expressed together.
Requirements amalgamation
Requirements are written in a standardized format; limits writer’s freedom.
Structured Specification
Works well for embedded/control systems.
Structured Specification
Too rigid for business system requirements.
Structured Specification
Used to supplement natural language
tabular specifications
useful when you have to define a number of possible alternative courses of action
tabular specifications
the official statement of what is required of the system developers.
the software requirements document
Should include both a definition of user requirements and a specification of the system requirements.
the software requirements document
It is NOT a design document
the software requirements document
it should set of WHAT the system should do rather than HOW it should do it.
the software requirements document
Defines expected readership.
Preface
Version history, rationale for new versions, summary of changes.
Preface
States the need for the system.
Introduction
Describes system functions & interaction with other systems.
Introduction
Explains fit with business/strategic objectives.
Introduction
Defines technical terms.
Glossary
Avoids assumptions about reader’s expertise.
Glossary
Describes services for users.
User Requirements Definition
Includes non-functional requirements.
User Requirements Definition
May use natural language, diagrams, or other notations.
User Requirements Definition
Specifies product & process standards to follow.
User Requirements Definition
High-level system overview.
System Architecture
Shows distribution of functions across modules.
System Architecture
Highlights reused components.
System Architecture
Describes functional and nonfunctional requirements in detail.
System requirements specification
Additional details may be added to nonfunctional requirements.
System requirements specification
Defines interfaces to other systems.
System requirements specification
Includes graphical models showing relationships between system components and the environment.
System models
Describes assumptions on which the system is based.
System evolution
Identifies anticipated changes due to hardware evolution, user needs, etc.
System evolution
Helps designers avoid decisions that constrain future changes.
System evolution
Provides detailed, specific information
Appendices
Hardware requirements: minimal and optimal configurations.
Appendices