1

Chapter 6System Engineering

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

System EngineeringSystem Engineering

Software Engineering occurs as a consequence of a process called system engineering.

System engineering process takes on different forms depending on the application domain in which it is applied.

1 Business Process engineering

2 Product engineering

Software Engineering occurs as a consequence of a process called system engineering.

System engineering process takes on different forms depending on the application domain in which it is applied.

1 Business Process engineering

2 Product engineering2

3

The HierarchyWorld view

Business orProduct Domain

Domain of interest

Domain view

System element

Element view

Detailed view

4

Product EngineeringSystem 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

System Engineering Cont.System Engineering Cont.

Definition of Computer based system: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

Elements of computer based system: 1. Software 4. Documentation

2. Hardware 5. Database

3. People 6. Procedures

Definition of Computer based system: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

Elements of computer based system: 1. Software 4. Documentation

2. Hardware 5. Database

3. People 6. Procedures5

6

Chapter 7Requirements Engineering

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

Requirements EngineeringRequirements Engineering

Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s)

Engineering: implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant . . . etc.

Requirement Engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system.

RE means that requirements for a product are defined, managed and tested systematically

Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s)

Engineering: implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant . . . etc.

Requirement Engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system.

RE means that requirements for a product are defined, managed and tested systematically 7

8

Requirements EngineeringRequirements Engineering

Requirement engineering process is accomplished through the execution of seven distinct functions:Inception—Establish a basic understanding of the problem and the nature of the solution. Elicitation—Draw out the requirements from stakeholders.Elaboration—Create an analysis model that represents information, functional, and behavioral aspects of the requirements.Negotiation—Agree on a deliverable system that is realistic for developers and customers.Specification—Describe the requirements formally or informally.Validation—Review the requirement specification for errors, ambiguities, omissions, and conflicts. Requirements management—Manage changing requirements.

Requirement engineering process is accomplished through the execution of seven distinct functions:Inception—Establish a basic understanding of the problem and the nature of the solution. Elicitation—Draw out the requirements from stakeholders.Elaboration—Create an analysis model that represents information, functional, and behavioral aspects of the requirements.Negotiation—Agree on a deliverable system that is realistic for developers and customers.Specification—Describe the requirements formally or informally.Validation—Review the requirement specification for errors, ambiguities, omissions, and conflicts. Requirements management—Manage changing requirements.

9

InceptionInception

Ask “context-free” questions Who is behind the request for this work? Who will use the solution (product/system)? What will be the economic benefits? How would you characterize “good” output from the

system? What problems does this solution address? What environment will the product be used in? Are you the right person to answer these questions? Are these question relevant? Can anyone else provide additional information? Should I be asking you anything else?

Ask “context-free” questions Who is behind the request for this work? Who will use the solution (product/system)? What will be the economic benefits? How would you characterize “good” output from the

system? What problems does this solution address? What environment will the product be used in? Are you the right person to answer these questions? Are these question relevant? Can anyone else provide additional information? Should I be asking you anything else?

10

Getting Requirements RightGetting Requirements Right “ The hardest single part of building a software system is deciding

what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

—Fred Brooks

“The seeds of major software disasters are usually sown within the first three months of commencing the software project.”

—Capers Jones

“We spend a lot of time—the majority of project effort—not implementing or testing, but trying to decide what to build.”

—Brian Lawrence

“ The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

—Fred Brooks

“The seeds of major software disasters are usually sown within the first three months of commencing the software project.”

—Capers Jones

“We spend a lot of time—the majority of project effort—not implementing or testing, but trying to decide what to build.”

—Brian Lawrence

11

Eliciting RequirementsEliciting Requirements

Why is it so difficult to clearly understand what the customer wants? Problems of Scope

The boundary of the system is ill-defined. Customers/users specify unnecessary technical detail that may confuse

rather than clarify objectives. Problems of understanding

Customers are not completely sure of what is needed. Customers have a poor understanding of the capabilities and limitations of

the computing environment. Customers don’t have a full understanding of their problem domain. Customers have trouble communicating needs to the system engineer. Customers omit detail that is believed to be obvious. Customers specify requirements that conflict with other requirements. Customers specify requirements that are ambiguous or untestable.

Problems of Volatility Requirements change over time.

Why is it so difficult to clearly understand what the customer wants? Problems of Scope

The boundary of the system is ill-defined. Customers/users specify unnecessary technical detail that may confuse

rather than clarify objectives. Problems of understanding

Customers are not completely sure of what is needed. Customers have a poor understanding of the capabilities and limitations of

the computing environment. Customers don’t have a full understanding of their problem domain. Customers have trouble communicating needs to the system engineer. Customers omit detail that is believed to be obvious. Customers specify requirements that conflict with other requirements. Customers specify requirements that are ambiguous or untestable.

Problems of Volatility Requirements change over time.

Elaboration, NegotiationElaboration, Negotiation Information obtained from the customer

during inception and elicitation is expanded and refined during elaboration.

The end result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem.

Requirement engineer reconcile the conflicts if any through the process of negotiation.

Information obtained from the customer during inception and elicitation is expanded and refined during elaboration.

The end result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem.

Requirement engineer reconcile the conflicts if any through the process of negotiation.

12

Specification, ValidationSpecification, Validation

Specification means different things to different people.

Specification can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

Work products produced as a consequence of requirements engineering are assessed for quality during validation step.

Primary requirement validation mechanism is the formal technical review.

Specification means different things to different people.

Specification can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

Work products produced as a consequence of requirements engineering are assessed for quality during validation step.

Primary requirement validation mechanism is the formal technical review. 13

Requirements ManagementRequirements Management Requirement management is a set of

activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds.

Requirement management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds.

14

Initiating the Requirements Engineering ProcessInitiating the Requirements Engineering Process

To get the project started in a way that will keep it moving forward toward a successful solution. Identifying the stakeholders Recognizing Multiple Viewpoints Working toward Collaboration Asking the first questions

To get the project started in a way that will keep it moving forward toward a successful solution. Identifying the stakeholders Recognizing Multiple Viewpoints Working toward Collaboration Asking the first questions

15

Eliciting RequirementsEliciting Requirements

Various approaches can be taken into consideration like• Collaborative Requirements Gathering• Quality Function Deployment• User Scenarios• Elicitation Work Products

Various approaches can be taken into consideration like• Collaborative Requirements Gathering• Quality Function Deployment• User Scenarios• Elicitation Work Products

16

17

What are the basic guidelines for conducting a collaborative requirements gathering meeting?

What are the basic guidelines for conducting a collaborative requirements gathering meeting?

Meetings are conducted and attended by all interested stakeholders. Rules for preparation and participation are established. Agenda should be formal enough to cover all important points, but

informal enough to encourage the free flow of ideas. A facilitator (can be customer, a developer, or an outsider) controls

the meeting. A definition mechanism (blackboard, flip charts, etc.) is used. During the meeting:

The problem is identified. Elements of the solution are proposed. Different approaches are negotiated. A preliminary set of solution requirements are obtained. The atmosphere is collaborative and non-threatening.

Meetings are conducted and attended by all interested stakeholders. Rules for preparation and participation are established. Agenda should be formal enough to cover all important points, but

informal enough to encourage the free flow of ideas. A facilitator (can be customer, a developer, or an outsider) controls

the meeting. A definition mechanism (blackboard, flip charts, etc.) is used. During the meeting:

The problem is identified. Elements of the solution are proposed. Different approaches are negotiated. A preliminary set of solution requirements are obtained. The atmosphere is collaborative and non-threatening.

18

Quality Function DeploymentQuality Function Deployment

Quality function deployment is a technique that translates the needs of the customer into technical requirements for software.

QFD identifies three types of requirements Normal requirements: reflect objectives and goals

stated for a product Expected requirements: are implicit to the product

or system and may be so fundamental that the customer does not explicitly state them.

Exciting requirements: reflect features that go beyond the customer’s expectations and prove to be very satisfying when present.

Quality function deployment is a technique that translates the needs of the customer into technical requirements for software.

QFD identifies three types of requirements Normal requirements: reflect objectives and goals

stated for a product Expected requirements: are implicit to the product

or system and may be so fundamental that the customer does not explicitly state them.

Exciting requirements: reflect features that go beyond the customer’s expectations and prove to be very satisfying when present.

User ScenariosUser Scenarios

It is difficult to move into more technical software engineering activities until the software team understands how these functions and features will be used by different classes of end users.

To accomplish this, developers and users create a set of scenarios often called use-cases.

It is difficult to move into more technical software engineering activities until the software team understands how these functions and features will be used by different classes of end users.

To accomplish this, developers and users create a set of scenarios often called use-cases. 19

20

Elicitation Work ProductsElicitation Work Products

What information is produced as a consequence of requirements gathering?

• Statement of need and feasibility.• Bounded Statement of scope.• List of participants in requirements elicitation.• Description of the system’s technical environment.• List of requirements and associated domain

constraints.• List of usage scenarios.• Any prototypes developed to refine requirements.

What information is produced as a consequence of requirements gathering?

• Statement of need and feasibility.• Bounded Statement of scope.• List of participants in requirements elicitation.• Description of the system’s technical environment.• List of requirements and associated domain

constraints.• List of usage scenarios.• Any prototypes developed to refine requirements.

21

Developing Use-CasesDeveloping Use-Cases

A use-case scenario is a story about how someone or something external to the software (known as an actor) interacts with the system.

Each scenario answers the following questions:• Who is the primary actor, the secondary actor(s)? What are the actor’s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the story is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external

environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

A use-case scenario is a story about how someone or something external to the software (known as an actor) interacts with the system.

Each scenario answers the following questions:• Who is the primary actor, the secondary actor(s)? What are the actor’s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the story is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external

environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

22

Use-Case DiagramUse-Case Diagram

23

Elements of the Analysis ModelElements of the Analysis Model

Scenario-based elements Use-case—How external actors interact with the system

(use-case diagrams; detailed templates) Functional—How software functions are processed in the

system (flow charts; activity diagrams) Class-based elements

The various system objects (obtained from scenarios) including their attributes and functions (class diagram)

Behavioral elements How the system behaves in response to different events

(state diagram) Flow-oriented elements

How information is transformed as if flows through the system (data flow diagram)

Scenario-based elements Use-case—How external actors interact with the system

(use-case diagrams; detailed templates) Functional—How software functions are processed in the

system (flow charts; activity diagrams) Class-based elements

The various system objects (obtained from scenarios) including their attributes and functions (class diagram)

Behavioral elements How the system behaves in response to different events

(state diagram) Flow-oriented elements

How information is transformed as if flows through the system (data flow diagram)

24

Activity Diagram for REActivity Diagram for RE

25

Class DiagramClass Diagram

26

State DiagramState Diagram

27

Analysis PatternsAnalysis PatternsPattern name:Pattern name: Captures the essence of the pattern. Captures the essence of the pattern.

Intent:Intent: What the pattern accomplishes or represents. What the pattern accomplishes or represents.

Motivation:Motivation: A scenario that illustrates how the pattern solves a problem. A scenario that illustrates how the pattern solves a problem.

Forces and context:Forces and context: External issues (forces) that affect how the pattern is External issues (forces) that affect how the pattern is used, and external issues resolved when the pattern is applied. used, and external issues resolved when the pattern is applied.

Solution:Solution: How the pattern is applied to solve the problem; emphasizes How the pattern is applied to solve the problem; emphasizes structural and behavioral issues.structural and behavioral issues.

ConsequencesConsequences: What happens when the pattern is applied; what trade-: What happens when the pattern is applied; what trade-offs exist during its application.offs exist during its application.

DesignDesign: How the pattern can be achieved via known design patterns.: How the pattern can be achieved via known design patterns.

Known usesKnown uses: Examples of uses within actual systems.: Examples of uses within actual systems.

Related patternsRelated patterns: Patterns related to the named pattern because: Patterns related to the named pattern because

(1)(1) they are commonly used with the named pattern;they are commonly used with the named pattern;

(2)(2) they are structurally similar to the named pattern;they are structurally similar to the named pattern;

(3)(3) they are a variation of the named pattern.they are a variation of the named pattern.

28

Negotiating RequirementsNegotiating Requirements

Identify the key stakeholders These are the people who will be involved in the

negotiation Determine each of the stakeholders “win

conditions” Win conditions are not always obvious

Negotiate Work toward a set of requirements that lead to “win-win”

Identify the key stakeholders These are the people who will be involved in the

negotiation Determine each of the stakeholders “win

conditions” Win conditions are not always obvious

Negotiate Work toward a set of requirements that lead to “win-win”

29

Validating RequirementsValidating Requirements Is each requirement consistent with the objective of the system? Have all requirements been specified at the proper level of abstraction? Is the requirement really necessary? Is each requirement bounded and unambiguous? Does each requirement have attribution? Do any requirements conflict with other requirements? Is each requirement achievable in the system’s technical environment? Is each requirement testable, once implemented? Does the model reflect the system’s information, function and behavior? Has the model been appropriately “partitioned”? Have appropriate requirements patterns been used?

Is each requirement consistent with the objective of the system? Have all requirements been specified at the proper level of abstraction? Is the requirement really necessary? Is each requirement bounded and unambiguous? Does each requirement have attribution? Do any requirements conflict with other requirements? Is each requirement achievable in the system’s technical environment? Is each requirement testable, once implemented? Does the model reflect the system’s information, function and behavior? Has the model been appropriately “partitioned”? Have appropriate requirements patterns been used?

30

Example CRG MeetingExample CRG Meeting

First CRG meeting of the SafeHome project. After Q&A session (inception meeting), stakeholders write a

two page product request, which is delivered to those attending the first CRG meeting.

Attendees are asked to make a rough list of objects, services, constraints, and performance criteria for the product.

At the meeting, a combined list is created in each topic. Subgroups write mini-specifications for each list item. Relevant features in mini-specifications are added to the list.

First CRG meeting of the SafeHome project. After Q&A session (inception meeting), stakeholders write a

two page product request, which is delivered to those attending the first CRG meeting.

Attendees are asked to make a rough list of objects, services, constraints, and performance criteria for the product.

At the meeting, a combined list is created in each topic. Subgroups write mini-specifications for each list item. Relevant features in mini-specifications are added to the list.

31

Example CRG MeetingExample CRG Meeting Our research indicates that the market for home management

systems is growing at a rate of 40 percent per year. The first SafeHome function we bring to market should be the home security function. Most people are familiar with “alarm systems” so this would be an easy sell.

The home security function would protect against and/or recognize a variety of undesirable “situations” such as illegal entry, fire, flooding, carbon monoxide levels, and others. It’ll use our wireless sensors to detect each situation, can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected.

Our research indicates that the market for home management systems is growing at a rate of 40 percent per year. The first SafeHome function we bring to market should be the home security function. Most people are familiar with “alarm systems” so this would be an easy sell.

The home security function would protect against and/or recognize a variety of undesirable “situations” such as illegal entry, fire, flooding, carbon monoxide levels, and others. It’ll use our wireless sensors to detect each situation, can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected.

32

Example CRG MeetingExample CRG Meeting Objects – control panel, smoke detectors, window and door

sensors, motion detectors, an alarm, an event (sensor has been activated), a display, a PC, telephone numbers, a telephone call, …

Services – configuring the system, setting the alarm, monitoring the sensors, dialing the phone, programming the control panel, reading the display, …

Constraints – System must recognize when sensors are not operating, must be user friendly, must interface directly to a standard phone line, …

Performance criteria – Sensor event should be recognized within one second, an event priority scheme should be implemented, …

Objects – control panel, smoke detectors, window and door sensors, motion detectors, an alarm, an event (sensor has been activated), a display, a PC, telephone numbers, a telephone call, …

Services – configuring the system, setting the alarm, monitoring the sensors, dialing the phone, programming the control panel, reading the display, …

Constraints – System must recognize when sensors are not operating, must be user friendly, must interface directly to a standard phone line, …

Performance criteria – Sensor event should be recognized within one second, an event priority scheme should be implemented, …

33

Example CRG MeetingExample CRG Meeting

Mini-specification for Control Panel

The Control Panel is a wall-mounted unit that is approximately 9 x 5 inches in size. The control panel has wireless connectivity to sensors and a PC. User interaction occurs through a keypad containing 12 keys. A 2 x 2 inch LCD display provides user feedback. Software provides interactive prompts, echo, and similar functions.

Mini-specification for Control Panel

The Control Panel is a wall-mounted unit that is approximately 9 x 5 inches in size. The control panel has wireless connectivity to sensors and a PC. User interaction occurs through a keypad containing 12 keys. A 2 x 2 inch LCD display provides user feedback. Software provides interactive prompts, echo, and similar functions.