You are on page 1of 14

Requirements

„ user vs. system requirements


… user requirements: description of what services that
REQUIREMENTS system is expected to provide and the constraints
under which it must operate
ENGINEERING … system requirements: detailed information about
the system functions, services and operational
constraints that are to be implemented.

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

Requirements Engineering Reqts. Elicitation and Analysis


„ activities „ some problems/difficulties
… feasibility
study … stakeholders don’t know what they want
… requirements elicitation and analysis … stakeholders express requirements in their own
… requirements specification terms
… requirements validation … differentstakeholders may have conflicting
requirements.
… organisational and political factors may influence
the system requirements.
… requirements change during the analysis process
Reqts. Elicitation and Analysis Reqts. Elicitation and Analysis
„ activities „ classic elicitation techniques
… discovery … interviews
… classification and organization … research
… prioritization and negotiation … questionnaires
… documentation … observation
… forms analysis
… prototyping

Reqts. Elicitation and Analysis Reqts. Elicitation and Analysis


„ other approaches „ other approaches (continued)
… viewpoints: way of structuring requirements to … scenarios: real-life examples of how the system can
represent perspectives of different stakeholders be used; may include the following:
„ interactor viewpoint – people or systems that „ description of the starting situation
interact directly with the system „ description of the normal flow of events
„ indirect viewpoint – stakeholders who influence „ description of what can go wrong
requirements „ information about other concurrent activities
„ domain viewpoint – domain characteristics and
„ description of the state when the scenario finishes
constraints that influence the requirements (e.g.,
… use cases
the law)

Reqts. Elicitation and Analysis Requirements Specification


„ work products after requirements elicitation „ natural language
… statement of need and feasibility … typical approach
… bounded statement of scope … problems with natural language specification
… list of stakeholders „ ambiguity (prone to different interpretations)

… description of the technical environment „ over-flexibility (different ways of stating the same

… list of requirements (preferably organized by


thing)
function) „ lack of modularization (inadequate to structure
requirements)
… prototypes developed to better define requirements
Requirements Specification Requirements Specification
„ graphical models „ forms-based
… process models, sequence diagram, data models, … includes the following
state-machine models, object models, data-flow „ definition of the function or entity
models, etc. „ description of inputs and where they come from
„ tables „ description of outputs and where they go to

„ structured language „ indication of other entities required

… freedom of writer is limited by a predefined template „ pre and post conditions (if appropriate)

… imposes a standard and a degree of uniformity „ side effects (if any)

… limits the terminology that may be used


… maintains the expressiveness of natural language

Requirements Specification Requirements Specification


„ software requirements specification (SRS): official „ sample structure
statement of system requirements … Preface
… represents WHAT the system should do, not HOW … Introduction
it should be done … Glossary
… complete specification may include the SRS, … User requirements definition
models and the prototype
… System architecture
„ IEEE requirements standard: defines a generic … System requirements specification
structure for a requirements document
… System, models
… introduction,
general description, specific
… Appendices
requirements, appendices, index
… Index

Requirements Validation Requirements Validation


„ assessment of the quality of the requirements „ good practices
(checked against characteristics) … review requirements formally and informally, early
„ determines whether the requirements actually and often.
define what the customer wants … use checklists to find typical defects.
… ensure that all requirements are in scope.
„ check for inconsistencies, omissions and errors
… check for characteristics of excellent requirements.
„ range from informal to formal … check for error handling
„ techniques … ensure freedom from design and implementation
… specification reviews details
… prototyping … ensure that requirements can serve as basis for
design and testing
… test case generation
Requirements Validation Requirements Management
„ guide questions: „ process of identifying, understanding, tracking and
… do you understand exactly what the requirement controlling changes to system requirements
means? „ requirements are inevitably incomplete and
… does the set of requirements make sense?
inconsistent
… new requirements emerge
… is the requirement valid and worth pursuing?
… priority of requirements may change (caused by:
business environment change, technical environment
change, better understanding of the system)
… system customers and end-user requirements may
conflict

Requirements Management Requirements Management


„ Requirement Management Planning „ other guidelines
… requirements identification … baseline and control versions of requirements
… change management process: focused on the … define a requirements change control process
impact and cost of changes … establish and charter a change control board
… traceability policies … perform requirements change impact analysis
„ keep sufficient amount of information about
… maintain history of requirements changes
requirements relationships
„ types of traceability: source, dependency, features … track requirements status
or design (represented using traceability matrices) … measure requirements stability
… CASE tool support … maintain a requirements traceability matrix

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

Software Design Key Design Techniques


„ design principles (continued) „ abstraction
… design should be structured to accommodate „ decomposition and modularization
change „ encapsulation/information hiding
… technical reviews or design walkthroughs should be
„ defined interfaces
conducted to minimize semantic errors and assess
design quality „ low coupling and high cohesion
… design must be a readable, understandable guide
for those who will generate code and those who will
test the software

Some Key Design Issues Some Key Design Issues


„ concurrency „ error handling and recovery
… main concurrent activities? … what is the system behavior when failure occurs?
… how is their interaction managed? … how are exceptional circumstances handled?
„ workflow and event handling „ persistence of data
… activities
inside a workflow? … which data needs to persist?
… how are events handled? … how complex is the data?
„ distribution „ security
… how is the system distributed physically (and „ communication
virtually)?
Design Process Architectural Design
„ architectural design „ establishes a basic structural framework that
„ interface design identifies the major components of system and the
„ component design communication among these components
„ data design „ focuses on architectural issues such as
„ algorithm design … control structure
… protocols for communication
Note that overall design strategy may vary: … synchronization and data access
… function-oriented … functionality and composition of design elements
… data-oriented
… selection among design alternatives
… object-oriented

Architectural Design Architectural Design


„ objectives „ other issues
… stakeholder communication … ensure that the architecture is appropriate not only
… analysis for the operations, but also for deployment and
„ communication of the understanding of the solution maintenance
„ software engineers can make principled choices … design decisions can enhance specific attributes
among design alternatives „ performance (localization of operations)
„ aids in complexity management „ safety (isolation of safety-critical components

… large-scale reuse „ availability (include redundant components)


„ maintainability (use fine-grained, independent
components)

Architectural Design Architectural Styles


„ the architect „ pipe and filter (pipeline)
… acts as the emissary of the architecture …a component reads streams of data on its inputs
… is the bridge between the developers and the and produces streams of data on its outputs,
project manager delivering a complete instance of the result in a
… ensures that appropriate modeling is being done
standard order
… accomplished by applying a local transformation to
… identifies suitable tools and design environments
the input streams and computing incrementally so
… resolves disputes and technical issues
output begins before input is consumed
… anticipates on technical evolution
… components are termed “filters”; “pipes” transmit
the output of a filter as inputs to another
Architectural Styles Architectural Styles
„ layered (abstract machine model) „ implicit invocation
… organizes a system into layers, each of which … components do not explicitly invoke a process
provide a set of services …a component broadcasts one or more events, and
… communication is limited to adjacent layers components can register interest in such events by
… layers are built up from low-level, more primitive associating a procedure with the event
behavior to high-level behavior
„ process-control
„ repository
… widely used for machine control applications and
… consistsof a central data store and a set of are typically modeled via finite state machines
independent components that access the data store

Architectural Styles Architectural Styles


„ blackboard „ client-server
… variation of the repository model which consists of … system is organized as a set of services and
the following components: associated servers and clients that access and use
„ knowledge sources: components that provide these services
application dependent knowledge … only the servers have identities that are known in
„ blackboard: a shared repository of problems,
advance
partial solutions, suggestions and contributed … clients access the servers via remote procedure
information. calls or SQL
„ control shell: controls the flow of problem- … evolved from mainframe architectures and file
solving activity in the system sharing architectures

Architectural Styles Architectural Styles


„ two-tier „ multi-tier
… client-server applications that ran on a workstation … the user interface, functional process logic, data
but accessed data from a database server storage and data access are developed and
… later architectures split the application itself into two maintained as independent modules, most often on
parts: a shared component for business logic that separate platforms
ran on the server and local clients that implemented … layers
the user interface „ presentation tier

„ logic tier / business logic tier / transaction tier

„ 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

Architectural Styles Architectural Styles


„ distributed systems architectures „ distributed systems architectures
… distributed system: collection of autonomous … users in different locations can readily be served
computers, connected through a network and … concurrent processing
distribution middleware, which enables computers … replication of functionality or data ensures a more
to coordinate their activities and to share the robust service
resources of the system, so that users perceive
… not all the functional nodes need be up at once
the system as a single, integrated computing
facility … diverse systems may be connected

Distributed Systems Architectures Distributed Systems Architectures


„ peer-to-peer (P2P) „ peer-to-peer (P2P)
… exploits diverse connectivity between participants in … pure P2P does not have the notion of clients or
a network and the cumulative bandwidth of the servers but equal peer nodes; hybrid P2P has a
network participants server that keeps information on the peers and
… all nodes provide resources, including bandwidth, responds to requests for such information
storage space and computing power … used in file sharing, VoIP, instant messaging, media
… distributed nature increases robustness by streaming, publication distribution
replicating data over multiple peers and enabling
peers to find the data even without a server
Distributed Systems Architectures Distributed Systems Architectures
„ grid computing „ grid computing
… consists of pools of servers, storage systems, and … speed up applications, maximize the availability of
networks (heterogeneous and loosely-coupled resources to users and encourage collaboration
resources) configured as a single large system so … major components: security, user interface,
that the power of multiple-systems resources can workload management, scheduler, resource
be delivered to a single user point for a specific management
purpose … standards and technologies: OGSA (Open Grid
… intended to virtualize resources to solve problems Services Architecture), OGSI (Open Grid Services
… enables otherwise idle computer resources to be Infrastructure), WSRF (Web Services Resource
used (CPU, data, bandwidth, software) Framework), CORBA, NorduGrid, Globus, GridBus

Distributed Systems Architectures Distributed Systems Architectures


„ cluster computing „ cluster computing
… technique of linking two or more computers into a … categories
network (usually via a LAN) in order to take „ high availability clusters (failover clusters) – ensure
advantage of the parallel processing power of those availability by employing redundancy
computers „ load-balancing clusters – enable efficient workload
… in comparison with a grid, a cluster is: of nodes by employing load-balancing nodes
„ more tightly coupled „ high-performance clusters – exploit the parallel

„ less heterogeneous processing power of multiple nodes


„ has a single system image

„ has a centralized job management and scheduling

Distributed Systems Architectures Distributed Systems Architectures


„ cluster computing „ cloud computing
… results in reduced cost, more processing power, … computing paradigm in which tasks are assigned to
scalability, improved network technology, a combination of connections, software and
availability services accessed over a network (the cloud)
… a cluster may be part of a grid … users can reach into a cloud for resources on-
… technologies and implementations: demand by using a thin client or access points such
„ MPI (Message Passing Interface), PVM (Parallel
as a phone or a laptop
Virtual Machine), Beowulf, Linux-HA, RedHat … a cloud may be a resource in a grid
Cluster Suite, Sun Cluster, Microsoft Cluster
Server, Oracle ClusterWare
Distributed Systems Architectures Distributed Systems Architectures
„ cloud computing „ cloud computing
… typical implementations … sample applications
„ SaaS (Software as a Service) – the cloud provides
„ Google Apps: provides common business
software (such as HR applications) to clients applications online that are accessed from a Web
browser
„ utility computing – provision of storage and virtual
„ Google App Engine: platform for building and
servers for a fee hosting web applications on Google servers
… technologies: XML, SOAP, REST, AJAX „ AWS (Amazon Web Services): set of web services
by Amazon.com; includes the following:
… EC2 (Amazon Elastic Compute Cloud): allows clients to
“rent” an arbitrary number of virtual machines to run their
applications
… S3 (Amazon Simple Storage Service): provides unlimited
storage services

Distributed Systems Architectures Distributed Systems Architectures


„ service-oriented architecture (SOA) „ service-oriented architecture (SOA)
… enables the creation of applications that are built by … makes applications easily adapt to changing
combining loosely coupled and interoperable technologies and integrate with other applications
services … technologies: REST, SOAP, CORBA, RPC, RMI,
Web Services
… services – independent software components with
defined interfaces that can be called to perform their … web service: software system designed to support
interoperable machine-to-machine interaction over a
tasks in a standard way, without the service having
network; has an interface described in a machine-
foreknowledge of the calling application, and without the processable format (specifically WSDL); other systems
application having or needing knowledge of how the interact with it in a manner prescribed by its description
service actually performs its tasks using SOAP messages, typically conveyed using HTTP
with an XML serialization in conjunction with other Web-
related standards [W3C]

<element name=“CustomerInfoRequest”> <element name=“CustomerInfoRequest”>


… …
<element name=“account” type=“string”/> <element name=“account” type=“string”/>
… …

Distributed Systems Architectures </element>


<element name=“CustomerInfoResponse”>
… Directory
</element>
<element name=“CustomerInfoResponse”>

<element name=“name” type=“string”/> <element name=“name” type=“string”/>
Q
„ service-oriented architecture (SOA) <element name=“phone” type=“string”/>
L ue <element name=“phone” type=“string”/>
<element name=“street1” type=“string”/> SD ry <element name=“street1” type=“string”/>
re<element name=“street2” type=“string”/>
gW
<element name=“street2” type=“string”/>
… web service <element name=“city” type=“string”/>
sin
sp
<element
on name=“city” type=“string”/>
<element name=“state” type=“string”/>n u <element Directory
se name=“state” queries
type=“string”/>
„ SOAP web service – all attachments (except t io
<element name=“postalcode” type=“string”/> s name=“postalcode”type=“string”/>
<element
rip uname=“country”
sin
sc
<element name=“country” type=“string”/> <element type=“string”/>
binary) are carried by SOAP; service description is … de … g
W
</element> ice </element> SD
in WSDL rv <m:GetCustomerInfo…>
Se <account>1069</account> L
</m:GetCustomerInfo>
„ REST web service – based on the concept of a Service Service
provider consumer
XML service request based on WSDL
resource (anything with a URI); require little
infrastructure except for HTTP and XML (HTTP XML service response based on WSDL
GET, DELETE, POST, PUT) <m:GetCustomerInfoResponse…>
<name>Barry & Associates, inc.</name>
<phone>952-892-6113</phone>
<street1>13504 4th Ave S</street1>
<street2></street2>
<city>Burnsville</city>
<state>MN</state>
<postalcode>55337</postalcode>
<country>United States</country>
</m:GetCustomerInfoResponse>
Distributed Systems Architectures Interface Design
„ service-oriented architecture (SOA) „ describes how the software communicates within
… web service itself, to systems that interact with it, and with
„ Web Services Description Language (WSDL) - humans who use it
XML-based service description that describes the … internal interface: represent the interfaces between
public interface, protocol bindings and message modules
formats required to interact with a web service … external interface: interfaces (external data and
„ Universal Description, Discovery, and Integration external control) between the software and other
(UDDI) - An XML-based registry to publish service non-human procedures and consumers of information
descriptions (WSDL) and allow their discovery
… human-computer/user interface
„ XACML - a markup language for expressing
access control rules and policies

User Interface Design User Interface Design


„ addresses the usability quality of software „ begins with an understanding of the intended
… learnability users
… response time or speed of operation „ understand how user tasks map to tasks that are
… robustness (user error tolerance) to be implemented in the context of a UI
… recoverability „ principles
„ human factors … ease of use, ease of learning, user familiarity, user
… limitedshort-term memory acceptance, user control, consistency, minimal
surprise, recoverability, user guidance, user
… people make mistakes
diversity
… people are different
“A common mistake that people make when trying to design
… people have different interaction preferences
something completely foolproof is to underestimate the ingenuity
of complete fools”

User Interface Design User Interface Design


„ information presentation „ color display
… consider factors such as volatility of information, … highlights information
required precision of values, and appropriateness … helps users understand complex information
of information display … can support user tasks
… provide alternative presentations (analog versus.
… some guidelines
digital, textual versus graphical)
„ do not over-use color in the display
… data visualization for large amounts of data should
„ limit the number of colors used
reveal relationships among such data
„ use color change to show change in system status
… provide meaningful feedback
„ use color coding in a consistent way

„ be careful about color pairings


User Interface Design User Interface Design
„ error messages „ other guidelines
… poor error messages can affect acceptability … allvisual information is organized according to a
… messages should be polite, concise, consistent and design standard that is maintained throughout all
constructive screen displays (labels, colors, abbreviations,
… consider users’ backgrounds and experience in
information display, navigation and data input)
message design … keep it simple (beware of “featuritis”)

… consider the following factors in wording messages … use affordances

„ context (relevant to current task) … use appropriate metaphors and UI elements


„ skill level (tailored to user skills and experience) … organize screen geography accordingly
„ style (positive messages) … use upper and lower case, indentation, white space
„ culture and text grouping to aid in understanding.

User Interface Design User Interface Design


„ other guidelines (continued) „ other guidelines (continued)
… reduce demand on short-term memory via visual … let the user control interactive flow
cues … prevent users from doing unnecessary tasks
… provide indicators that enable the user to put the … allows user interaction to be interruptible and
current task into a meaningful context (e.g., window undoable
titles, graphical icons, color coding) … minimize input actions

… justify data appropriately … do not make changes on interactive models that


have created user expectations
… provide for flexible interaction … verify destructive action and critical operations

… use shortcuts to facilitate interaction … use appropriate dialog options

… user interface should be intuitive … provide help that is well-organized

User Interface Design User Interface Design


„ web-related guidelines „ web-related guidelines
… consider web conventions and user expectations in … allow quick access via an efficient site hierarchy
web page design … interface metaphors should be simple, familiar, and
… provide concrete, visible, easy-to-understand logical
navigational cues (e.g., consistent “landmarks”, … provide functional stability, good visual design and
breadcrumb trails, basic links to home and major high editorial standards
navigation points, no dead-end pages) … be aware of browser variations
… design should be built on a consistent pattern of
modular units that all share the same basic layout Whether designing a Web site, a user interface for an application,
grids, graphic themes, editorial conventions, and or anything else, design decisions should be driven by the
organization hierarchies purpose of the deliverable and the needs of the user.
User Interface Design User Interface Design
„ summary of guidelines „ summary of guidelines (continued)
… simplicity … safety
… support „ keep the user out of trouble; user is assured of
„ place the user in control and provide proactive recoverability
assistance, make the user task simpler and faster … versatility
… encouragement „ support alternate interaction techniques

„ tolerance, flexibility, make actions predictable and … personalization


reversible „ allow users to customize
… satisfaction … affinity
„ create a feeling of progress and achievement „ bring objects to life through good visual design
… visibility
„ make all needed objects available at all times

User Interface Design


„ summary of guidelines
… progression
„ facilitate continuous advancement in knowledge
and skill
SOFTWARE
… efficacy
„ do not impede efficient use by a skilled user
CONSTRUCTION
… context
„ interface should suit operational context THE IMPLEMENTATION PHASE
… feedback
… structure
„ coherent and useful organization

Software Implementation Software Implementation


„ Implementation concerns „ coding guidelines
… complexity … length of code
„ ensure that details are addressed and “work „ short does not always mean better; 30-second rule
around” problems in order to cope with complexity … readability and sensible organization
… change … formatting
„ code should be resilient to anticipated change „ indentation and alignment; case conventions; white
… validation and verification space; spaces in expressions; proper splitting of
„ code structure should facilitate the verification and long statements across lines
validation process … naming conventions
… standards compliance „ variables, classes, class members, interfaces,

… platform sensitivity packages, exceptions, etc.


Software Implementation Software Implementation
„ coding guidelines „ coding guidelines
… modular programming … resource clean-up
… variables … coding standards
„ declare immediately before use; intermediate „ industry (general and platform-dependent)
variables; unused variables „ organizational
… efficiency „ project/product
„ optimized code „ personal
… documentation
„ what and why of code; block comments vs. in-line
comments, header comments
… safe and defensive programming

You might also like