Professional Documents
Culture Documents
Requirements Requirements
functional vs. non-functional requirements characteristics of requirements
functional requirements: statements of the services
unambiguous
that a system should provide, how the system
complete
should react to particular input and how the system
consistent (with company goals, system objectives,
should behave in particular situations. other requirements)
non-functional requirements: constraints (timing,
traceable
performance, reliability, development process,
realistic
standards) on the services or functions offered by
the system; normally apply to the system as a
verifiable
whole
valid
description of the technical environment over-flexibility (different ways of stating the same
freedom of writer is limited by a predefined template pre and post conditions (if appropriate)
Software Design
design
first
step in the development phase for any
SOFTWARE engineered product or system
process of applying various techniques and
DESIGN principles for the purpose of defining a device,
process or system in sufficient detail to permit its
physical realization
Software Design Software Design
software design design principles
iterativeprocess through which requirements are
design process should not suffer from tunnel vision
translated into a “blueprint” for building software
design should be traceable to analysis (implement
multistep process in which representation of data explicit and implicit requirements)
structure, program structure, interface characteristics
design should “minimize the intellectual distance”
and procedural detail are synthesized from the
between the software and the real world problem
requirements
design should exhibit uniformity and integration
(IEEE) process of defining the software architecture,
components, modules, interfaces, and data for a
design is not coding, coding is not design
software system to satisfy specified requirements
data tier
Architectural Styles Architectural Styles
model-view-controller (MVC) model-view-controller (MVC)
decouples data access and business logic from
general flow for a web application:
data presentation and user interaction via the a user presses a button in an html page
controller
controller handles the input event from the user
model – domain-specific representation of the
information on which the application operates; interface (frequently via a handler or callback)
(e.g., persistent storage mechanism such as a controller accesses the model based on the user’s
database) action (update the model)
view – renders the model into a form suitable for a view generates the appropriate user interface,
interaction, typically a user interface element waits for further user interaction
controller – processes and responds to events,
typically user actions, and may invoke changes on
the model