1 Chapter 10/11 System Engineering AND Analysis Concepts and Principles

1

Chapter 10/11Chapter 10/11System EngineeringSystem Engineering

AND AND Analysis Concepts and Analysis Concepts and

PrinciplesPrinciples

2

RequiremeRequirementnt

A REQUIREMENT may range from a A REQUIREMENT may range from a high-level abstract statement of a high-level abstract statement of a service or of a system constraint to a service or of a system constraint to a detailed mathematical functional detailed mathematical functional specification.specification.

This multiplicity is inevitable as This multiplicity is inevitable as requirements may serve multiple requirements may serve multiple functions.functions.

Also there are various types of Also there are various types of requirements.requirements.

3

Types of Types of RequirementsRequirements

User requirements--User requirements--Statements in natural Statements in natural language plus diagrams of the services the system language plus diagrams of the services the system provides and its operational constraints. Written for provides and its operational constraints. Written for customerscustomers

System requirements--System requirements--A structured document A structured document setting out detailed descriptions of the system setting out detailed descriptions of the system services. Written as a contract between client and services. Written as a contract between client and contractorcontractor

Software specification--Software specification--A detailed software A detailed software description which can serve as a basis for a design or description which can serve as a basis for a design or implementation. Written for developers.implementation. Written for developers.

4

Types of Types of RequirementsRequirements

Functional requirements--Functional requirements--Statements of Statements of services the system should provide, how the system services the system should provide, how the system should react to particular inputs and how the system should react to particular inputs and how the system should behave in particular situations.should behave in particular situations.

Non-functional requirements--Non-functional requirements--constraints constraints on the services or functions offered by the system on the services or functions offered by the system such as timing constraints, constraints on the such as timing constraints, constraints on the development process, standards, etc.development process, standards, etc.

Domain requirements--Domain requirements--Requirements that Requirements that come from the application domain of the system and come from the application domain of the system and that reflect characteristics of that domain.that reflect characteristics of that domain.

5

Requirements Requirements EngineeringEngineering

The processes used for RE vary widely The processes used for RE vary widely depending on the application domain, depending on the application domain, the people involved and the organisation the people involved and the organisation developing the requirementsdeveloping the requirements

However, there are a number of generic However, there are a number of generic activities common to all processesactivities common to all processes

Requirements elicitationRequirements elicitation Requirements analysisRequirements analysis Requirements validationRequirements validation Requirements managementRequirements management

6

The The HierarchyHierarchy

World viewBusiness or

Product Domain

Domain of interest

Domain view

System element

Element view

Detailed view

7

Types of Requirements Types of Requirements EngineeringEngineering

Information EngineeringInformation Engineering

Traditional EngineeringTraditional EngineeringViewpoint Requirements EngineeringViewpoint Requirements EngineeringScenario Requirements EngineeringScenario Requirements EngineeringModel/Method Oriented EngineeringModel/Method Oriented Engineering

8

Information Information Engineering (IE)Engineering (IE) uses an integrated set of procedures, uses an integrated set of procedures,

methods, and tools to identify how methods, and tools to identify how information systems can best meet the information systems can best meet the strategic goals of an enterprisestrategic goals of an enterprise

focuses first on the enterprise and then on focuses first on the enterprise and then on specific business areasspecific business areas

creates enterprise models, data models and creates enterprise models, data models and process modelsprocess models

creates a framework for better information creates a framework for better information management distribution, and controlmanagement distribution, and control

9

The IE Process The IE Process StagesStages Information strategy Information strategy planningplanning (ISP) (ISP)

strategic goals definedstrategic goals defined success factors/business rules identifiedsuccess factors/business rules identified enterprise model createdenterprise model created

Business area Business area analysis analysis (BAA)(BAA) processes/services modeledprocesses/services modeled interrelationships of processes and datainterrelationships of processes and data

Application EngineeringApplication Engineering a.k.a ... software component engineeringa.k.a ... software component engineering modeling applications/procedures that address modeling applications/procedures that address

(BAA) and constraints of ISP(BAA) and constraints of ISP Construction and deliveryConstruction and delivery

using CASE and 4GTs, testingusing CASE and 4GTs, testing

10

Information Strategy Information Strategy Planning (ISP)Planning (ISP) Management issuesManagement issues

define strategic business define strategic business goals/objectivesgoals/objectives

isolate critical success factorsisolate critical success factors conduct analysis of technology impactconduct analysis of technology impact perform analysis of strategic systemsperform analysis of strategic systems

Technical issuesTechnical issues create a top-level data modelcreate a top-level data model cluster by business/organizational areacluster by business/organizational area refine model and clusteringrefine model and clustering

11

Defining Objectives and Goals Defining Objectives and Goals (ISP)(ISP) Objective—general statement of directionObjective—general statement of direction

Goal—defines measurable objective: “reduce Goal—defines measurable objective: “reduce manufactured cost of our product”manufactured cost of our product” Subgoals:Subgoals:

decrease reject rate by 20% in first 6 monthsdecrease reject rate by 20% in first 6 monthsgain 10% price concessions from suppliersgain 10% price concessions from suppliersre-engineer 30% of components for ease of re-engineer 30% of components for ease of

manufacture during first yearmanufacture during first year objectives tend to be strategic while goals objectives tend to be strategic while goals

tend to be tacticaltend to be tactical

12

Business Area Analysis Business Area Analysis (BAA)(BAA) define “naturally cohesive groupings of define “naturally cohesive groupings of

business functions and data” (Martin)business functions and data” (Martin) perform many of the same activities as ISP, perform many of the same activities as ISP,

but narrow scope to individual business areabut narrow scope to individual business area identify existing (old) information systems / identify existing (old) information systems /

determine compatibility with new ISP modeldetermine compatibility with new ISP model define systems that are problematic define systems that are problematic defining systems that are incompatible with defining systems that are incompatible with

new information modelnew information model begin to establish re-engineering prioritiesbegin to establish re-engineering priorities

13

The BAA The BAA ProcessProcess

salesacct

manufacturing

QC

eng’ring

distribution

admin.

ProcessDecomp.Diagram

Matricese.g.,

entity/processmatrix

Process Flow

ModelsData

Model

14

Product Product EngineeringEngineering

System analysis(World view)

The completeproduct

capabilities

Componentengineering

(Domain view)

Processing requirement

Analysis & DesignModeling

(Element view)

Construction&

Integration(Detailed view)

software

function

SoftwareEngineering

programcomponent

hardware

data behavior

15

Product Architecture Product Architecture TemplateTemplate

user interface processing

inputprocessing

outputprocessing

maintenance and self-test

process and controlfunctions

16

Architecture Flow Architecture Flow DiagramDiagram

bar codereader

subsystem

bar codedecoding

subsystem

data baseaccess

subsystem

shuntcontrol

subsystem

reportformating

subsystem

diagnosticssubsystem

operatorinterface

subsystem

shuntcontroller

mainframecommunications

driver

operator requests CLSS queries, reports, displays

shunt control statusbar code acquisition request

bar code

pulse tach input

linespeed

bar codereader status

sensor status

raw barcode data

partnumber

reportrequests

binlocation

key

sort records

formatedreporting data

sorting reports

shunt commands

CLSS reports

BCR statusshunt status

communications status

timing/location data

operatorinterface

data acquisitioninterface diagnostic interface output interface

CLSS processing & control

sensor dataacquisitionsubsystem

17

Traditional Traditional EngineeringEngineering

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

18

Traditional Requirements Traditional Requirements EngineeringEngineeringComponentsComponents

Elicitation — determining what the customer Elicitation — determining what the customer requires by interviewing, holding Joint requires by interviewing, holding Joint Application Development (JAD) sessions, or Application Development (JAD) sessions, or simply taking to the user(s).simply taking to the user(s).

Analysis & negotiation — understanding the Analysis & negotiation — understanding the relationships among various customer relationships among various customer requirements and shaping those requirements and shaping those relationships to achieve a successful result.relationships to achieve a successful result.

Requirements specification — building a Requirements specification — building a tangible model or models for requirements. tangible model or models for requirements.

19


System Modeling — building a representation System Modeling — building a representation of requirements that can be assessed for of requirements that can be assessed for correctness, completeness, and consistency correctness, completeness, and consistency (example process, data, scenario, or event (example process, data, scenario, or event model).model).

Validation — reviewing the model for Validation — reviewing the model for correctness, completeness, and consistency.correctness, completeness, and consistency.

Management — identify, control and track Management — identify, control and track requirements and the changes that will be requirements and the changes that will be made to them.made to them.

20


Feasibilitystudy

Requi ementselicitation and

analysisRequirementsspecification

Requirementsvalidation

FeasibilityReport

SystemModels

User and System Requirements

RequirementsDocument

21

Feasibility Feasibility StudyStudy

A feasibility study decides whether or A feasibility study decides whether or not the proposed system is worthwhilenot the proposed system is worthwhile

The input to the feasibility study is The input to the feasibility study is outline description of the system and outline description of the system and how it will be used within an how it will be used within an organization.organization.

The results of the feasibility study The results of the feasibility study should be a report which recommends should be a report which recommends whether or not it is worth carrying on whether or not it is worth carrying on with requirements engineering and with requirements engineering and system development process.system development process.

22

Elicitation and Elicitation and AnalysisAnalysis

Sometimes called requirements Sometimes called requirements elicitation or requirements discoveryelicitation or requirements discovery

Involves technical staff working with Involves technical staff working with customers to find out about the customers to find out about the application domain, the services that application domain, the services that the system should provide and the the system should provide and the system’s operational constraintssystem’s operational constraints

May involve end-users, managers, May involve end-users, managers, engineers involved in maintenance, engineers involved in maintenance, domain experts, trade unions, etc. domain experts, trade unions, etc. These are called These are called stakeholdersstakeholders

23

Elicitation and Elicitation and AnalysisAnalysis

Elicitation and analysis is a difficult Elicitation and analysis is a difficult process for a number of these process for a number of these reasons:reasons:Stakeholders don’t know what they really wantStakeholders don’t know what they really wantStakeholders express requirements in their own Stakeholders express requirements in their own

termstermsDifferent stakeholders may have conflicting Different stakeholders may have conflicting

requirementsrequirementsOrganisational and political factors may Organisational and political factors may

influence the system requirementsinfluence the system requirementsThe requirements change during the analysis The requirements change during the analysis

process. New stakeholders may emerge and the process. New stakeholders may emerge and the business environment changebusiness environment change

24

Requirements Requirements Elicitation Elicitation

and Analysis Processand Analysis Process

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry

25

ActivitiActivitieses

Domain understanding—Domain understanding—Analyst must develop their Analyst must develop their understanding of the application domain.understanding of the application domain.

Requirements collection—Requirements collection—This is the process of This is the process of interacting with stakeholders in the system to discover interacting with stakeholders in the system to discover their requirements.their requirements.

Classification—Classification—This activity takes the unstructured This activity takes the unstructured collection of requirements and organized them into collection of requirements and organized them into coherent clusterscoherent clusters

Conflict resolution—Conflict resolution—Inevitably, where multiple Inevitably, where multiple stakeholder are involved, requirements will conflictsstakeholder are involved, requirements will conflicts

Prioritisation—Prioritisation—In any set of requirements some will be In any set of requirements some will be important than others.important than others.

Requirements checking—Requirements checking—The requirements are The requirements are checked to discover if they are complete, consistent and checked to discover if they are complete, consistent and in accordance with what stakeholders really want from in accordance with what stakeholders really want from the system.the system.

26

ViewPoint Oriented ViewPoint Oriented ElicitationElicitation

In viewpoint oriented elicitation, the main In viewpoint oriented elicitation, the main stakeholders are the focus for gathering stakeholders are the focus for gathering requirementsrequirements

Stakeholders represent different ways of Stakeholders represent different ways of looking at a problem or problem viewpointslooking at a problem or problem viewpoints

This multi-perspective analysis is This multi-perspective analysis is important as there is no single correct way important as there is no single correct way to analyse system requirementsto analyse system requirements

Types of viewpoint:Types of viewpoint: Data sources or sinksData sources or sinks--Viewpoints are responsible for --Viewpoints are responsible for

producing or consuming data. Analysis involves producing or consuming data. Analysis involves checking that data is produced and consumed and that checking that data is produced and consumed and that assumptions about the source and sink of data are assumptions about the source and sink of data are validvalid

27

Scenario Based Scenario Based ElicitationElicitation

In scenario based elicitation the main focus is defining In scenario based elicitation the main focus is defining the different scenarios of the business area.the different scenarios of the business area.

Scenarios are descriptions of how a system is used in Scenarios are descriptions of how a system is used in practicepractice

They are helpful in requirements elicitation as people They are helpful in requirements elicitation as people can relate to these more readily than abstract can relate to these more readily than abstract statement of what they require from a systemstatement of what they require from a system

Scenarios are particularly useful for adding detail to Scenarios are particularly useful for adding detail to an outline requirements descriptionan outline requirements description

Scenario descriptions:Scenario descriptions: System state at the beginning of the scenarioSystem state at the beginning of the scenario Normal flow of events in the scenarioNormal flow of events in the scenario What can go wrong and how this is handledWhat can go wrong and how this is handled Other concurrent activitiesOther concurrent activities System state on completion of the scenarioSystem state on completion of the scenario

28

Use Case Based Use Case Based ElicitationElicitation

In use case elicitation, the focus is on In use case elicitation, the focus is on the use cases of the business areas.the use cases of the business areas.

Use-cases are a scenario based Use-cases are a scenario based technique in the UML which identify the technique in the UML which identify the actors in an interaction and which actors in an interaction and which describe the interaction itselfdescribe the interaction itself

A set of use cases should describe all A set of use cases should describe all possible interactions with the systempossible interactions with the system

Sequence diagrams may be used to add Sequence diagrams may be used to add detail to use-cases by showing the detail to use-cases by showing the sequence of event processing in the sequence of event processing in the systemsystem

29

Requirements Requirements ValidationValidation

Concerned with demonstrating Concerned with demonstrating that the requirements define the that the requirements define the right system. right system.

(the system the customer really wants)(the system the customer really wants)

Requirements error costs are Requirements error costs are high so validation is very high so validation is very importantimportant

Fixing a requirements error after delivery may cost up Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation to 100 times the cost of fixing an implementation errorerror

30


Steps involved in validating Steps involved in validating requirements:requirements:

The The need of the user should be shown to be validneed of the user should be shown to be valid—A user —A user may think that a system is needed to perform certain functions may think that a system is needed to perform certain functions but further though and analysis may identify additional or but further though and analysis may identify additional or different needs and any set of requirements is inevitably a different needs and any set of requirements is inevitably a compromise across the user community.compromise across the user community.

The requirements should be shown to be The requirements should be shown to be consistentconsistent. Any one . Any one requirement should not conflict with any other.requirement should not conflict with any other.

The requirements should be shown to be The requirements should be shown to be completecomplete—The —The definition should include all functions and constraints intended definition should include all functions and constraints intended by the system user.by the system user.

The requirements should be shown to be The requirements should be shown to be realisticrealistic—There is no —There is no point in specifying requirements which are unrealizable. It may point in specifying requirements which are unrealizable. It may be acceptable to anticipate some hardware developments but be acceptable to anticipate some hardware developments but developments in software technology are much less predictable.developments in software technology are much less predictable.

31


Validity. Validity. Does the system provide the functions which best support Does the system provide the functions which best support

the customer’s needs?the customer’s needs?

Consistency. Consistency. Are there any requirements conflicts?Are there any requirements conflicts?

Completeness. Completeness. Are all functions required by the customer included?Are all functions required by the customer included?

Realism. Realism. Can the requirements be implemented given available Can the requirements be implemented given available

budget and technologybudget and technology

Verifiability. Verifiability. Can the requirements be checked?Can the requirements be checked?

32

Requirements Validation Requirements Validation TechniquesTechniques

Requirements reviewsRequirements reviews----Systematic Systematic manual analysis of the requirementsmanual analysis of the requirements

PrototypingPrototyping----Using an executable model of Using an executable model of the system to check requirements. the system to check requirements.

Test-case generationTest-case generation——Developing tests Developing tests for requirements to check testabilityfor requirements to check testability

Automated consistency analysisAutomated consistency analysis----Checking the consistency of a structured Checking the consistency of a structured requirements descriptionrequirements description

33

RevieReviewsws

Regular reviews should be held while Regular reviews should be held while the requirements definition is being the requirements definition is being formulatedformulated

Both client and contractor staff should Both client and contractor staff should be involved in reviewsbe involved in reviews

Reviews may be formal (with Reviews may be formal (with completed documents) or informal. completed documents) or informal. Good communications between Good communications between developers, customers and users can developers, customers and users can resolve problems at an early stageresolve problems at an early stage

34

Review Review ChecksChecks

Verifiability--Is the requirement Verifiability--Is the requirement realistically testable?realistically testable?

Comprehensibility--Is the requirement Comprehensibility--Is the requirement properly understood?properly understood?

Trace ability--Is the origin of the Trace ability--Is the origin of the requirement clearly stated?requirement clearly stated?

CASE tool support--Adaptability. Can CASE tool support--Adaptability. Can the requirement be changed without a the requirement be changed without a large impact on other requirements?large impact on other requirements?

35

Requirements Requirements ManagementManagement

Requirements management is the Requirements management is the process of managing changing process of managing changing requirements during the requirements requirements during the requirements engineering process and system engineering process and system developmentdevelopment

Requirements are inevitably incomplete Requirements are inevitably incomplete and inconsistentand inconsistent

New requirements emerge during the process as New requirements emerge during the process as business needs change and a better business needs change and a better understanding of the system is developedunderstanding of the system is developed

Different viewpoints have different requirements Different viewpoints have different requirements and these are often contradictoryand these are often contradictory

36

Requirements Requirements ChangeChange

The priority of requirements from The priority of requirements from different viewpoints changes during different viewpoints changes during the development processthe development process

System customers may specify System customers may specify requirements from a business requirements from a business perspective that conflict with end-perspective that conflict with end-user requirementsuser requirements

The business and technical The business and technical environment of the system changes environment of the system changes during its developmentduring its development

37

The Requirements The Requirements DocumentDocument

The requirements document produced The requirements document produced may have many names.may have many names.

IEEE refers to it as a SRS – System IEEE refers to it as a SRS – System Requirements SpecificationRequirements Specification

Your text refers to it as simply a Your text refers to it as simply a requirements documentrequirements document

Since this is a software engineering Since this is a software engineering course we will follow the the SRS by course we will follow the the SRS by IEEE.IEEE.

In the next section, we will describe In the next section, we will describe the contents of the IEEE SRS.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


DeMarco Notation

= is composed of

+ and

[ / ] either/or

{ }n repetitions (n times)

( ) optional

* * comments

40


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


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)

Documents

1 Chapter 10/11 System Engineering AND Analysis Concepts and Principles