Chapter 10/11 System Engineering AND Analysis Concepts and Principles

1
Chapter 10/11System EngineeringAND Analysis
Concepts and Principles
2
Requirement

• A REQUIREMENT may range from a high-level
  abstract statement of a service or of a system
  constraint to a detailed mathematical functional
  specification.
• This multiplicity is inevitable as requirements
  may serve multiple functions.
• Also there are various types of requirements.

3
Types of Requirements

• User requirements--Statements in natural language
  plus diagrams of the services the system provides
  and its operational constraints. Written for
  customers
• System requirements--A structured document
  setting out detailed descriptions of the system
  services. Written as a contract between client
  and contractor
• Software specification--A detailed software
  description which can serve as a basis for a
  design or implementation. Written for developers.

4
Types of Requirements

• Functional requirements--Statements of services
  the system should provide, how the system should
  react to particular inputs and how the system
  should behave in particular situations.
• Non-functional requirements--constraints on the
  services or functions offered by the system such
  as timing constraints, constraints on the
  development process, standards, etc.
• Domain requirements--Requirements that come from
  the application domain of the system and that
  reflect characteristics of that domain.

5
Requirements Engineering

• The processes used for RE vary widely depending
  on the application domain, the people involved
  and the organisation developing the requirements
• However, there are a number of generic activities
  common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management

6
The Hierarchy
Business or
Product Domain
World view
Domain of interest
Domain view
System element
Element view
Detailed view
7
Types of Requirements Engineering

• Information Engineering
• Traditional Engineering
• Viewpoint Requirements Engineering
• Scenario Requirements Engineering
• Model/Method Oriented Engineering

8
Information Engineering (IE)

• uses an integrated set of procedures, methods,
  and tools to identify how information systems can
  best meet the strategic goals of an enterprise
• focuses first on the enterprise and then on
  specific business areas
• creates enterprise models, data models and
  process models
• creates a framework for better information
  management distribution, and control

9
The IE Process Stages

• Information strategy planning (ISP)
• strategic goals defined
• success factors/business rules identified
• enterprise model created
• Business area analysis (BAA)
• processes/services modeled
• interrelationships of processes and data
• Application Engineering
• a.k.a ... software component engineering
• modeling applications/procedures that address
  (BAA) and constraints of ISP
• Construction and delivery
• using CASE and 4GTs, testing

10
Information Strategy Planning (ISP)

• Management issues
• define strategic business goals/objectives
• isolate critical success factors
• conduct analysis of technology impact
• perform analysis of strategic systems
• Technical issues
• create a top-level data model
• cluster by business/organizational area
• refine model and clustering

11
Defining Objectives and Goals (ISP)

• Objectivegeneral statement of direction
• Goaldefines measurable objective reduce
  manufactured cost of our product
• Subgoals
• decrease reject rate by 20 in first 6 months
• gain 10 price concessions from suppliers
• re-engineer 30 of components for ease of
  manufacture during first year
• objectives tend to be strategic while goals tend
  to be tactical

12
Business Area Analysis (BAA)

• define naturally cohesive groupings of business
  functions and data (Martin)
• perform many of the same activities as ISP, but
  narrow scope to individual business area
• identify existing (old) information systems /
  determine compatibility with new ISP model
• define systems that are problematic
• defining systems that are incompatible with new
  information model
• begin to establish re-engineering priorities

13
The BAA Process
admin.
manufacturing
QC
distribution
sales
acct
engring
Process Decomp. Diagram
Matrices e.g., entity/ process matrix
Process Flow Models
Data Model
14
Product Engineering
The complete
System analysis
product
(World view)
capabilities
Component
software
hardware
engineering
(Domain view)
Processing requirement
Analysis Design
function
behavior
data
Modeling
(Element view)
program
Software
component
Engineering
Construction

Integration
(Detailed view)
15
Product Architecture Template
16
Architecture Flow Diagram
operator
interface
operator
operator requests
CLSS queries, reports, displays
interface
subsystem
bar code acquisition request
shunt control status
sorting reports
CLSS processing control
timing/location data
report
requests
shunt
shunt
part
bar code
control
bar code
number
controller
reader
subsystem
decoding
subsystem
subsystem
raw bar
bin
shunt commands
code data
location
bar code
data base
access
CLSS reports
subsystem
report
line
formating
key
sensor data
speed
subsystem
acquisition
subsystem
sort records
mainframe
communications
driver
BCR status
shunt status
diagnostics
sensor status
pulse tach input
subsystem
formated
reporting data
communications status
data acquisition
bar code
interface
diagnostic interface
output interface
reader status
17
Traditional Engineering

• Traditional engineering techniques for gathering
  and documenting requirements has a slightly
  different focus than the information engineering
  focus on strategic planning and enterprise
  orientation.

18
Traditional Requirements EngineeringComponents

• Elicitation determining what the customer
  requires by interviewing, holding Joint
  Application Development (JAD) sessions, or simply
  taking to the user(s).
• Analysis negotiation understanding the
  relationships among various customer requirements
  and shaping those relationships to achieve a
  successful result.
• Requirements specification building a tangible
  model or models for requirements.

19
Requirements Engineering

• System Modeling building a representation of
  requirements that can be assessed for
  correctness, completeness, and consistency
  (example process, data, scenario, or event
  model).
• Validation reviewing the model for correctness,
  completeness, and consistency.
• Management identify, control and track
  requirements and the changes that will be made to
  them.

20
Requirements Engineering
R
e
q
u
i
e
m
e
n
t
s
F
e
a
s
i
b
i
l
i
t
y
e
l
i
c
i
t
a
t
i
o
n

a
n
d
s
t
u
d
y
a
n
a
l
y
s
i
s
R
e
q
u
i
r
e
m
e
n
t
s
s
p
e
c
i
f
i
c
a
t
i
o
n
Feasibility Report
R
e
q
u
i
r
e
m
e
n
t
s
v
a
l
i
d
a
t
i
o
n
System Models
User and System Requirements
Requirements Document
21
Feasibility Study

• A feasibility study decides whether or not the
  proposed system is worthwhile
• The input to the feasibility study is outline
  description of the system and how it will be used
  within an organization.
• The results of the feasibility study should be a
  report which recommends whether or not it is
  worth carrying on with requirements engineering
  and system development process.

22
Elicitation and Analysis

• Sometimes called requirements elicitation or
  requirements discovery
• Involves technical staff working with customers
  to find out about the application domain, the
  services that the system should provide and the
  systems operational constraints
• May involve end-users, managers, engineers
  involved in maintenance, domain experts, trade
  unions, etc. These are called stakeholders

23
Elicitation and Analysis

• Elicitation and analysis is a difficult process
  for a number of these reasons
• Stakeholders dont know what they really want
• Stakeholders express requirements in their own
  terms
• Different stakeholders may have conflicting
  requirements
• Organisational and political factors may
  influence the system requirements
• The requirements change during the analysis
  process. New stakeholders may emerge and the
  business environment change

24
Requirements Elicitation and Analysis Process
R
e
q
u
i
r
e
m
e
n
t
s
d
e
f
i
n
i
t
i
o
n

a
n
d
s
p
e
c
i
f
i
c
a
t
i
o
n
R
e
q
u
i
r
e
m
e
n
t
s
v
a
l
i
d
a
t
i
o
n
D
o
m
a
i
n
P
r
i
o
r
i
t
i
z
a
t
i
o
n
u
n
d
e
r
s
t
a
n
d
i
n
g
P
r
o
c
e
s
s
e
n
t
r
y
R
e
q
u
i
r
e
m
e
n
t
s
C
o
n
f
l
i
c
t
c
o
l
l
e
c
t
i
o
n
r
e
s
o
l
u
t
i
o
n
C
l
a
s
s
i
f
i
c
a
t
i
o
n
25
Activities

• Domain understandingAnalyst must develop their
  understanding of the application domain.
• Requirements collectionThis is the process of
  interacting with stakeholders in the system to
  discover their requirements.
• ClassificationThis activity takes the
  unstructured collection of requirements and
  organized them into coherent clusters
• Conflict resolutionInevitably, where multiple
  stakeholder are involved, requirements will
  conflicts
• PrioritisationIn any set of requirements some
  will be important than others.
• Requirements checkingThe requirements are
  checked to discover if they are complete,
  consistent and in accordance with what
  stakeholders really want from the system.

26
ViewPoint Oriented Elicitation

• In viewpoint oriented elicitation, the main
  stakeholders are the focus for gathering
  requirements
• Stakeholders represent different ways of looking
  at a problem or problem viewpoints
• This multi-perspective analysis is important as
  there is no single correct way to analyse system
  requirements
• Types of viewpoint
• Data sources or sinks--Viewpoints are responsible
  for producing or consuming data. Analysis
  involves checking that data is produced and
  consumed and that assumptions about the source
  and sink of data are valid

27
Scenario Based Elicitation

• In scenario based elicitation the main focus is
  defining the different scenarios of the business
  area.
• Scenarios are descriptions of how a system is
  used in practice
• They are helpful in requirements elicitation as
  people can relate to these more readily than
  abstract statement of what they require from a
  system
• Scenarios are particularly useful for adding
  detail to an outline requirements description
• Scenario descriptions
• System state at the beginning of the scenario
• Normal flow of events in the scenario
• What can go wrong and how this is handled
• Other concurrent activities
• System state on completion of the scenario

28
Use Case Based Elicitation

• In use case elicitation, the focus is on the use
  cases of the business areas.
• Use-cases are a scenario based technique in the
  UML which identify the actors in an interaction
  and which 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

29
Requirements Validation

• Concerned with demonstrating that the
  requirements define the right system.
• (the system the customer really wants)
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error

30
Requirements Validation

• Steps involved in validating requirements
• The need of the user should be shown to be
  validA user may think that a system is needed to
  perform certain functions but further though and
  analysis may identify additional or different
  needs and any set of requirements is inevitably a
  compromise across the user community.
• The requirements should be shown to be
  consistent. Any one requirement should not
  conflict with any other.
• The requirements should be shown to be
  completeThe definition should include all
  functions and constraints intended by the system
  user.
• The requirements should be shown to be
  realisticThere is no point in specifying
  requirements which are unrealizable. It may be
  acceptable to anticipate some hardware
  developments but developments in software
  technology are much less predictable.

31
Requirements Validation

• Validity.
• Does the system provide the functions which best
  support the customers needs?
• Consistency.
• Are there any requirements conflicts?
• Completeness.
• Are all functions required by the customer
  included?
• Realism.
• Can the requirements be implemented given
  available budget and technology
• Verifiability.
• Can the requirements be checked?

32
Requirements Validation Techniques

• Requirements reviews--Systematic manual analysis
  of the requirements
• Prototyping--Using an executable model of the
  system to check requirements.
• Test-case generationDeveloping tests for
  requirements to check testability
• Automated consistency analysis--Checking the
  consistency of a structured requirements
  description

33
Reviews

• Regular reviews should be held while the
  requirements definition is being formulated
• Both client and contractor staff should be
  involved in reviews
• Reviews may be formal (with completed documents)
  or informal. Good communications between
  developers, customers and users can resolve
  problems at an early stage

34
Review Checks

• Verifiability--Is the requirement realistically
  testable?
• Comprehensibility--Is the requirement properly
  understood?
• Trace ability--Is the origin of the requirement
  clearly stated?
• CASE tool support--Adaptability. Can the
  requirement be changed without a large impact on
  other requirements?

35
Requirements Management

• Requirements management is the process of
  managing changing requirements during the
  requirements engineering process and system
  development
• Requirements are inevitably incomplete and
  inconsistent
• New requirements emerge during the process as
  business needs change and a better understanding
  of the system is developed
• Different viewpoints have different requirements
  and these are often contradictory

36
Requirements Change

• The priority of requirements from different
  viewpoints changes during the development process
• System customers may specify requirements from a
  business perspective that conflict with end-user
  requirements
• The business and technical environment of the
  system changes during its development

37
The Requirements Document

• The requirements document produced may have many
  names.
• IEEE refers to it as a SRS System Requirements
  Specification
• Your text refers to it as simply a requirements
  document
• Since this is a software engineering course we
  will follow the the SRS by IEEE.
• In the next section, we will describe the
  contents of the IEEE SRS.

38
Software Specification Tools- Data Dictionary
One of the requirements of the specification
document is the data dictionary. A data
dictionary is an important tool for software
development. The data dictionary- alias
encyclopedia - alias repository may contain many
items of information. Data Dictionary - for
interfaces (inputs, outputs, external
interfaces), data entities, data elements
(attributes), use cases, classes.
39
Software Specification Tools- Data Dictionary
DeMarco Notation is composed of
and / either/or n repetitions
(n times) ( ) optional comments
40
Software Specification Tools- Data Dictionary
It should include Name (of the item) Type
(use case, input, output, external interface,
class, class or entity element(attribute),
class operation..) Description Composition
definition using Demarco notation other data as
needed ONLY ONE ENTRY with the same name AND type.
41
Software Specification Tools- Data Dictionary
Example of composition (using demarco) SRF
student ssn student name (student address
classification) class information class
information class prefix class number
section number reference number ( building
number room number)