csci 387 quiz 2 Flashcards
requirements engineering
the process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed
system requirements
the descriptions of the system services and constraints that are generated during the RE process / structured document defining what should be implemented
requirement
may range from a high-level abstract statement of a service or system constraint to a detailed mathematical functional specification
types of requirements
user and system
user requirements
statements in natural language with diagrams; written for customers
system stakeholders
any person or organization affected by the system in some way and so who has legitimate interest
types of system stakeholders
end users, system managers, system owners, external stakeholders
functional requirement
services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations; may state what the system should not do; depends on the type of software
nonfunctional requirement
constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.; often apply to the system as a whole rather than individual features or services
domain requirement
constraints on the system from the domain of operation
problems arise when functional requirements are…
not precisely stated (may be interpreted in different ways by developers and users)
requirements should be both
complete and consistent (but this is impossible)
complete
include description of all facilities required
consistent
no conflicts or contradictions in description
a system may be useless without what kind of requirements and why?
nonfunctional - may affect overall architecture; a single NFR may generate functional requirements that define requirement system services
non-functional classifications
product requirements, organizational requirements, external requirements
product requirements
delivered product must behave in a particular way (e.g. speed, reliability)
organizational requirements
organizational policies, procedures (e.g. standards, implementation)
external requirements
arise from external factors (e.g. interoperability, legislative)
goal
a general intention of the user (such as ease of use); helpful to developers because conveys the intentions of users
metrics for specifying nonfunctional requirements
speed, size, ease of use, reliability, robustness, portability
generic activities in RE process
elicitation, analysis, validation, management
stages of requirements elicitation and analysis
discovery, classification and organization, prioritization and negotiation, specification
problems with requirements elicitation and analysis
stakeholders don’t know what they really want, express requirements in their own terms; different stakeholders may have conflicting requirements; organizational and political factors may influence system requirements; requirements change during analysis process
discovery
interacting with stakeholders to discover their requirements; also discover domain requirements
classification and organization
group related requirements and organize into cohesive clusters
prioritization and negotiation
prioritize requirements and resolve requirement conflicts
specification
document requirements and input into next round of spiral
interviewing
can be formal or informal; with stakeholders; part of RE process
types of interviewing
closed (predetermined questions) and open (explore various issues)
effective interviewing
be open-minded, prompt interviewee to get discussions going
problems with interviews
language gap between application specialists and requirements engineer; not good for understanding domain requirements
ethnography
work is usually richer and more complex than suggested by simple system models; effective for understanding existing processes but cannot identify new features
focused ethnography combines
ethnography with prototyping
stories
real-life examples of how a system can be used for a particular task; stakeholders can relate and comment
scenarios
a structured form of a user story
scenarios should include
description of starting situation description of normal flow of events description of what can go wrong information about concurrent events description of state where scenario finishes
requirements specification
the process of writing down user and system requirements in a requirements document
user requirements have to be
understandable by end-users and customers with no technical background
ways of wring requirements
natural language structured natural language design description languages graphical notations mathematical specifications
requirements and ? are inseparable
design
use cases
a kind of scenario included in UML; identify actors in an interaction and describe the interaction; a set of use cases should describe all possible interactions with the system
software requirements document
official statement of what is required of system developers; WHAT system should do rather than how
structure of requirements document
preface, intro, glossary, user requirements definition, system architecture, system requirements specification, system models, system evolution, appendices, index
requirements validation
demonstrating that the requirements define the system the customer really wants; important because of the high cost of requirements error
requirements checking
validity, consistency, completeness, realism, verifiability
requirements validation techniques
requirements reviews (systematic manual analysis of the requirements; involves client and contractor), prototyping, test-case generation
review checks
verifiability, comprehensibility, traceability, adaptability
requirements evolution
initial understanding of problem > initial requirements > changed understanding of problem > changes requirements
requirements management
the process of managing changing requirements; keep track of requirements and maintain links between dependent requirements
requirements management planning
identification, change management process, traceability policies, tool support
deciding if a requirements change should be accepted
problem analysis and change specification, change analysis and costing, change implementation
database entity
any object in the system we want to model and store information about; usually recognizable concepts, either concrete or abstract (person, place, thing, etc.)
database attribute
properties or features of an entity (can be single or a set)
database tuple
members of an entity (a set - order doesn’t matter)
in a database, entity is ?, attributes are ?, and tuples are ?
entity is the table
attributes are the columns
tuples are the rows
primary key
special attribute of an entity designated to uniquely identify all tuples (unique for each tuple, cannot be null, generally undefined; try to generate automatically)
foreign key
an attribute (or collection of attributes) in one entity that uniquely identifies a tuple of another entity or the same entity (refers to the primary key or a unique key from a second table; can connect to the same table)
types of database relationships
one to one, one to many, many to many, self referencing
CRUD operations
Create, Read (select-from-where), Update, Delete
web pages are written in
HTML
web server
a program running on a computer that delivers web pages in response to requests
do as much as possible on the ? side because ?
client; communication b/w client and server is costly
HTML stands for
Hypertext Markup Language
HTML (is/is not) a programming language
is not
HTML describes
content and structure
HTML is made up of building blocks called
elements
CSS stands for
Cascading Style Strucure
CSS describes the
appearance and layout of a web page
HTML + CSS yields a webpage that
doesn’t do anything
JavaScript
a programming language; no connection to java; no other options for web pages
HTML can embed JavaScript files with what tag
JavaScript has no ? and no ?
main method and no compilation (runs top to bottom)
const (cannot/can) be reassigned
cannot
don’t use ?, use let and const as much as possible
var
== and != are essentially broken in JS so use
=== and !==
event-driven programming
executes after some event fires (function known as event handler)
DOM
Document Object Model; tree of nodes corresponding to HTML elements on page
defer attribute will cause JavaScript to
execute after DOM
either use ? or ? to cause JavaScript to execute after the DOM
defer attribute or put the tag at the bottom
