September 15, 2009COMS W41561 COMS W4156: Advanced Software
Engineering Prof. Gail Kaiser September 15, 2009COMS W41562 Topics
covered in this lecture Software requirements System models
(introduction to Unified Modeling Language UML will be covered in
more depth later in the course) September 15, 2009COMS W41563
Software Requirements September 15, 2009COMS W41564 What is a
requirement? What is the (future) software system supposed to do?
Each requirement is a service or feature that the customer needs
from a system and/or a constraint under which it must be developed
and operated. May range from a high-level abstract statement to a
detailed mathematical specification. Requirements serve a dual
function May be the basis for a bid for a contract - therefore must
be open to interpretation; May be the basis for the contract itself
- therefore must be defined in detail. September 15, 2009COMS
W41565 User requirements Should describe functional and
non-functional requirements in such a way that they are
understandable by (future) system users who may have little
technical knowledge. User requirements are defined using natural
language, tables and diagrams as these can be understood by all
users. Usage scenarios, user stories, use cases, September 15,
2009COMS W41566 System requirements More detailed specifications of
system functions, services and constraints than user requirements.
They are intended to be a basis for developers to design the
system. They may be incorporated into the system contract.
September 15, 2009COMS W41567 Functional requirements Statements of
services and features the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations. Functional user requirements may be high-
level statements of what the system should do but functional system
requirements must describe the system services in detail. September
15, 2009COMS W41568 Example: The LIBSYS system A library system
that provides a single interface to a number of databases of
articles in different libraries. Users can search for, download and
print these articles for personal study. September 15, 2009COMS
W41569 Examples of functional requirements The user shall be able
to search either all of the initial set of databases or select a
subset from it. The system shall provide appropriate viewers for
the user to read documents in the document store. Every order for a
document shall be allocated a unique identifier, which the user
shall be able to copy to the accounts permanent storage area.
September 15, 2009COMS W Requirements imprecision Problems arise
when requirements are not precisely stated. Ambiguous requirements
may be interpreted in different ways by developers and users.
Consider the term appropriate viewers User intention - special
purpose viewer for each different document type; Developer
interpretation - Provide a text viewer that shows the contents of
the document. September 15, 2009COMS W Non-functional requirements
Define system properties and constraints, e.g., reliability,
response time, storage requirements, device capability, etc.
Process requirements may also be specified, mandating a particular
IDE (Integrated Development Environment), programming language or
development method. Non-functional requirements may be more
critical than functional requirements. If these are not met, the
system is useless. September 15, 2009COMS W Non-functional
classifications Product requirements Requirements that specify that
the delivered product must behave in a particular way, e.g.,
resource utilization, mean time to recovery, etc. Organizational
requirements Requirements that are a consequence of organizational
policies and procedures, e.g., process standards used, platform
rrestrictions, etc. External requirements Requirements that arise
from factors that are external to the system and its development
process, e.g., interoperability requirements, legislative
requirements, etc. September 15, 2009COMS W Non-functional
requirements examples Product requirement: The user interface for
LIBSYS shall be implemented as simple HTML without frames or Java
applets. Organizational requirement: The system development process
and deliverable documents shall conform to the process and
deliverables defined in XYZCo-SP- STAN-95. External requirement:
The system shall not disclose any personal information about
customers apart from their name and reference number to the
operators of the system. September 15, 2009COMS W Goals vs.
requirements Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be difficult to
verify. Goal A general intention of the user such as ease of use.
Verifiable non-functional requirement A statement based on some
measure that can be objectively tested. Goals are helpful to
developers as they convey the intentions of the system users.
September 15, 2009COMS W Examples A system goal The system should
be easy to use by experienced controllers and should be organized
in such a way that user errors are minimized. A verifiable
non-functional requirement Experienced controllers shall be able to
use all the system functions after a total of two hours training.
After this training, the average number of errors made by
experienced users shall not exceed two per day. September 15,
2009COMS W Requirements interaction Conflicts between different
non-functional requirements are common in complex systems.
Spacecraft system To minimize weight, the number of separate chips
in the system should be minimized. To minimize power consumption,
lower power chips should be used. However, using low power chips
may mean that more chips have to be used. Which is the most
critical requirement? September 15, 2009COMS W Requirements
completeness and consistency In principle, requirements should be
both complete and consistent. Complete: Should include descriptions
of all facilities required. Consistent: Should be no conflicts or
contradictions in the descriptions of the system facilities. In
practice, it may be impossible to produce a complete and consistent
requirements document. September 15, 2009COMS W Domain requirements
Derived from the application domain and describe system
characteristics and features that reflect the domain. Domain
requirements may be new functional requirements, constraints on
existing requirements or define specific computations. If domain
requirements are not satisfied, the system may be unworkable.
September 15, 2009COMS W Library system domain requirements There
shall be a standard user interface to all databases, which shall be
based on the Z39.50 standard. Z39.50 Because of copyright
restrictions, some documents must be deleted immediately upon
arrival. Depending on the users needs, these documents will either
be printed locally on the system server, for manually forwarding to
the user, or routed to a network printer. September 15, 2009COMS W
Domain requirements problems Understandability Requirements are
expressed in the language of the application domain; This jargon
may not be understood by the software engineers developing the
system. Implicitness Domain specialists understand the area so well
that they may not think of making the domain requirements explicit.
September 15, 2009COMS W Problems with natural language Lack of
clarity Precision is difficult without making the document hard to
read. Requirements confusion Functional and non-functional
requirements tend to be mixed up. Requirements amalgamation Several
different requirements may be expressed together. September 15,
2009COMS W Requirement problems LIBSYS shall provide a financial
accounting system that maintains records of all payments made by
users of the system. System managers may configure this system so
that frequent users may receive discounted rates. This requirements
statement includes both conceptual and detailed information
Describes the concept of a financial accounting system that is to
be included in LIBSYS; However, it also includes the detail that
managers can configure this system - this is unnecessary at this
level. September 15, 2009COMS W Guidelines for writing requirements
Invent a standard format and use it for all requirements.standard
format Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements. Use text
highlighting to identify key parts of the requirement. Avoid the
use of computer jargon. September 15, 2009COMS W Requirements vs.
design In principle, requirements should state what the system
should do and the design should describe how it does this. In
practice, requirements and design are inseparable A system
architecture may be designed to structure the requirements; The
system may inter-operate with other systems that generate design
requirements; The use of a specific design may be a domain
requirement. September 15, 2009COMS W System Models September 15,
2009COMS W Use cases Use cases are a scenario-based modeling
technique that identify the actors in an interaction and describe
the interaction itself. A set of use cases should describe all
possible interactions with the system. Sequence diagrams may be
used to add detail to use cases by showing the sequence of event
processing in the system. September 15, 2009COMS W LIBSYS use cases
September 15, 2009COMS W Article printing use case September 15,
2009COMS W Print article sequence September 15, 2009COMS W System
modeling System modeling helps the analyst to understand the
functionality of the system, and models are also used to
communicate with customers. Different models present the system
from different perspectives External perspective showing the
systems context or environment; Behavioral perspective showing the
behavior of the system; Structural perspective showing the system
or data architecture. September 15, 2009COMS W Model types Data
processing model showing how the data is processed at different
stages. Composition model showing how entities are composed of
other entities. Architectural model showing principal sub- systems.
Classification model showing how entities have common
characteristics. Stimulus/response model showing the systems
reaction to events. September 15, 2009COMS W Context models Context
models are used to illustrate the operational context of a system -
they show what lies outside the system boundaries. Social and
organizational concerns may affect the decision on where to
position system boundaries. Architectural models show the system
and its relationship with other systems. September 15, 2009COMS W
The context of an ATM system September 15, 2009COMS W Process
models Process models show the overall process and the processes
that are supported by the system. Data flow models may be used to
show the processes and the flow of information from one process to
another. September 15, 2009COMS W Equipment procurement process
September 15, 2009COMS W Behavioral models Behavioral models are
used to describe the overall behavior of a system. Two types of
behavioral model are: Data processing models that show how data is
processed as it moves through the system; State machine models that
show the systems response to events. These models show different
perspectives so both of them are needed to describe the systems
behavior. September 15, 2009COMS W Data-processing models Data flow
diagrams (DFDs) may be used to model the systems data processing.
These show the processing steps as data flows through a system.
DFDs are an intrinsic part of many analysis methods. Simple and
intuitive notation that customers can understand. Show end-to-end
processing of data. September 15, 2009COMS W Order processing DFD
September 15, 2009COMS W Data flow diagrams DFDs model the system
from a functional perspective. Tracking and documenting the data
associated with a process is helpful to develop an overall
understanding of the system. Data flow diagrams may also be used in
showing the data exchange between a system and other systems in its
environment. September 15, 2009COMS W Insulin pump DFD September
15, 2009COMS W State machine models Model the behavior of the
system in response to external and internal events. Show the
systems responses to stimuli, so are often used for modeling
real-time systems. State machine models show system states as nodes
and events as arrows between these nodes. When an event occurs, the
system moves from one state to another. September 15, 2009COMS W
Statecharts Allow the decomposition of a model into sub- models. A
brief description of the actions is included following the do in
each state. Can be complemented by tables describing the states and
the stimuli. September 15, 2009COMS W Microwave oven model
September 15, 2009COMS W Microwave oven state description September
15, 2009COMS W Microwave oven stimuli September 15, 2009COMS W
Microwave oven operation September 15, 2009COMS W Semantic data
models Used to describe the logical structure of data processed by
the system. An entity-relationship-attribute (ERA) model sets out
the entities in the system, the relationships between these
entities and the entity attributes Widely used in database design.
Can readily be implemented using relational databases. September
15, 2009COMS W Library semantic model September 15, 2009COMS W Data
dictionaries Data dictionaries are lists of all of the names used
in the system models. Descriptions of the entities, relationships
and attributes are also included. Advantages Support name
management and avoid duplication; Store of organizational knowledge
linking analysis, design and implementation; Many IDEs support data
dictionaries. September 15, 2009COMS W Data dictionary entries
September 15, 2009COMS W Object models Object models describe the
system in terms of object classes and their associations. An object
class is an abstraction over a set of objects with common
attributes and the services (operations) provided by each object.
(Not necessarily to be implemented directly as programming language
classes.) Various object models may be produced Inheritance models;
Aggregation models; Interaction models. September 15, 2009COMS W
Object models Natural ways of reflecting the real-world entities
manipulated by the system Abstract entities are more difficult to
model using this approach Object class identification is recognized
as a difficult process requiring a deep understanding of the
application domain Object classes reflecting domain entities are
often reusable across systems September 15, 2009COMS W Inheritance
models Organize the domain object classes into a hierarchy. Classes
at the top of the hierarchy reflect the common features of all
classes. Object classes inherit their attributes and services from
one or more super-classes (base classes). These may then be
specialized as necessary. It is sometimes difficult to avoid
duplication in different branches of a class hierarchy design.
September 15, 2009COMS W Object models and UML UML (Unified
Modeling Language) is a representation devised by the developers of
widely used object-oriented analysis and design methods.UML It has
become an effective standard for object- oriented modeling.
Notation Object classes are rectangles with the name at the top,
attributes in the middle section and operations in the bottom
section; Relationships between object classes (known as
associations) are shown as lines linking objects; Inheritance is
referred to as generalization and is shown upwards rather than
downwards in a hierarchy. September 15, 2009COMS W Library class
hierarchy September 15, 2009COMS W User class hierarchy September
15, 2009COMS W Multiple inheritance Rather than inheriting the
attributes and services from a single parent class, a modeling
system that supports multiple inheritance allows object classes to
inherit from several super-classes. (Multiple inheritance may or
may not be supported by the implementation programming language.)
This can lead to semantic conflicts where attributes/services with
the same name in different super-classes have different semantics.
Multiple inheritance makes class hierarchy reorganization more
complex. September 15, 2009COMS W Multiple inheritance September
15, 2009COMS W Object aggregation An aggregation model shows how
classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in
semantic data models. September 15, 2009COMS W Object aggregation
September 15, 2009COMS W Object behavior modeling A behavioral
model shows the interactions between objects to produce some
particular system behavior that is specified as a use case.
Sequence diagrams (or collaboration diagrams) in the UML are used
to model interaction between objects. September 15, 2009COMS W
Issue of electronic library items September 15, 2009COMS W Final
Notes September 15, 2009COMS W Teams Announced Next Week! Hopefully
before class on Tuesday Teams will be posted on the website team
pageteam page If you already formed a full team, assume youre good
to go (but let us know asap if anything changes!) Start thinking
about the Project ConceptProject Concept September 15, 2009COMS W
Upcoming Deadlines Team project concept due September 29 th Project
concept feedback by October 6 th First iteration begins October 6
th September 15, 2009COMS W COMS W4156: Advanced Software
Engineering Prof. Gail Kaiser
