Dr. Thomas Hicks Computer Science Department Trinity University

Dr. Thomas HicksComputer Science Department

Trinity University 1

Software EngineeringCSCI 3321

Software Engineering : A Practitioner’s Approach

RequirementsEngineering

Dr. Thomas E. HicksComputer Science Department

Trinity University

Thanks To Ian Sommerville & Roger Pressman For Much Of The Slide Content

Chapter 7

RequirementsEngineering

Creating the Requirements/Specifications can’t be too hard can it?

After All the user does know what he/she wants don’t they?

Requirements Engineering Can’t Be Too Hard Can It?

YES

NO

Pressman

“It Is Your Worst Nightmare!”

Requirements Engineering is the set of processes used to discover, analyze and validate system requirements.

Requirements Engineering helps software engineers to better understand the problem they will work to solve.

Requirements Engineering encompasses the set of tasks that leads to an understanding of what the business impact of the software willbe, what the customer wants, and howthe end user will interact with the software.

What Is Requirements Engineering?

Requirements Elicitation Process Activities

Domain Understanding

Requirements Collection

Classification

Conflict Resolution

Prioritization

Requirements Checking

RequirementsEngineeringProcesses

Requirements Engineering & Management

4 Analysis & Design Processes

1. Inception - ask questions to understand people & problem

2. Elicitation - elicit requirements from all stakeholders

3. Elaboration - create an analysis model that identifies data, function and behavioral requirements

4. Negotiation - agree on a deliverable system that is realistic for developers and customers

2 Post Analysis & Design Processes

1. Validation - demonstrating that the requirements define the system that the customer really wants

2. Requirements Management - managing changing requirements

The Processes used for Requirements Engineering can vary widely depending on the application domain, the people involved and the organization developing the requirements

They can vary like the processes in the Waterfall Model.

For purposes of our exams, we shall use the

4 Analysis & Design Processes &

2 Post Analysis & Design Processes

illustrated in these slides.

Requirements Engineering & Management

Requirements Engineering4 Analysis & Design Processes

Inception

Requirements Engineering – Inception - 1

It is the function of the Inception stage/function of Requirements Engineering to ask a set of questions that establish …

Basic understanding of the problem

The people who want a solution

The nature of the solution that is desired

The effectiveness of preliminary communication and collaboration between the customer and the developer

Important Stage – Get In Or Get Out!

Identify stakeholders

“who else do you think I should talk to?”

Recognize multiple points of view

Work toward collaboration

The first questions

1. Who is behind the request for this work?

2. Who will use the solution?

3. What will be the economic benefit of a successful solution

4. Is there another source for the solution that you need?

Requirements Engineering – Inception - 2


Elicitation

Requirements Elicitation is the process of combining the technical staff with the customers to work out the User Requirements [Customers], the System Requirements [Contract], and the Software Specification [Developers]

Requirements Elicitation is also called “Requirements Discovery”

Objectives Of Requirements Elicitation

1. Determine the application domain

2. Determine the services that the system should provide

3. Determine the system’s operational constraints

Requirements Engineering – Elicitation - 1

1. Meetings are conducted and attended by both software engineers and customers

2. Rules for preparation and participation are established3. An agenda is suggested 4. A "facilitator" (can be a customer, a developer, or an

outsider) controls the meeting5. A "definition mechanism" (can be work sheets, flip

charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used

6. The goals are A. To identify the problemB. To propose elements of the solutionC. Negotiate different approaches, andD. Specify a preliminary set of solution requirements

Elicitation Meeting GuidelinesRequirements Engineering

Requirements Elicitation Participants

Requirements Elicitation participants may involve

End-Users - receivers of system services

Managers

Engineers involved in Maintenance

Domain Experts

Trade Unions, etc.

Those individuals have a stake in the system; they are called Stakeholders

Eliciting Requirements Flowchart

Use QFD to prioritize

requirements

informally prioritize

requirements

formal prioritization?

Create Use-cases

yes noElic it requirements

write scenario

define actors

complete template

draw use-case diagram

Conduct FASTmeetings

Make lists offunctions, classes

Make lists ofconstraints, etc.

Elicitation Work Products Might Include

A statement of need and feasibility.

A bounded statement of scope for the system or product.

A list of customers, users, and other stakeholders who participated in requirements elicitation

A description of the system’s technical environment.

A list of requirements (preferably organized by function) and the domain constraints that apply to each.

A set of usage scenarios that provide insight into the use of the system or product under different operating conditions.

Any prototypes developed to better define requirements.

Feasibility Study – Designer Questions

A Feasibility Study decides whether or not the proposed system is a worthwhile venture

A Designer Portion of the Feasibility Study is a short focused study that checks

1. If the system contributes to organizational objectives

2. If the system can be engineered using current technology and within budget [can the critical specifications can be met?]

3. If the system can be integrated with other systems that are used

A Stakeholder Portion of the Feasibility Study is a short focused study that checks

1. What if the system wasn’t implemented?

2. What are current process problems?

3. How will the proposed system help?

4. What will be the integration problems?

5. Is new technology needed?

6. Will new user training be necessary?

Feasibility Study – Stakeholder Questions

Viewpoint-Oriented Elicitation

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 analyze system requirements

Viewpoints are a natural way to structure requirements elicitation

It is relatively easy to decide if a viewpoint is valid

ATMBanking

Example

Banking ATM System Example

Auto-Teller - provides some automated banking services

Simplified System - offers some services to customers of the bank

Narrower range of services to customers

Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds

Auto Teller ViewpointsWho Would Be The Stakeholders

Bank Customers

Representatives Of Other Banks

Hardware & Software Maintenance Engineers

Marketing Department

Bank Managers & Counter Staff

Database Administrators & Security Staff

Communications Engineers

Personnel Department

Others? – You Do!

Method-Based Analysis

There are Structured Methods to help the project manager to organize and categorize views. VORD

Methods have different emphases. Some are designed for requirements elicitation, others are close to design methods

A Viewpoint-Oriented Requirements Definition (VORD) is one of the more common models.

Widely used approach to requirements analysis.

VORD Method Flow4 Basic Steps

Viewpointidentification

Viewpointstructuring

Viewpointdocumenta tion

Viewpointsystem mapping

Viewpoint-Oriented Requirements DefinitionVORD is an acronym for _____________________________Viewpoint-Oriented Requirements Definition

You Need Know No Specifics About VORD!

4 Step VORD Process Model

1. Viewpoint Identification

Discover viewpoints which receive system services and identify the services provided to each viewpoint

2. Viewpoint Structuring

Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy

3. Viewpoint Documentation

Refine the description of the identified viewpoints and services

4. Viewpoint-System Mapping

Transform the analysis to an object-oriented design – Use Case You Need Know No Specifics About VORD!

Viewpoint Identification - ATMMany Can Views Which Help Determine Others

Querybalance

Gettransactions

Cashwithdrawal

Transactionlog

Machinesupplies

Cardreturning

Remotesoftwareupgrade

Ordercheques

Userinterface

Accountinformation

Messagelog

Softwaresize Invalid

userSystem cost Printe

r Security

Cardretention

Stolencard

Orderstatement

Remotediagnostics

ReliabilityUpdateaccount

Fundstransfer

Messagepassing

Cardvalidation

Customerdatabase

Manager

Accountholder

Foreigncustomer

Hardwaremaintenance

Bankteller


Viewpoint Structuring - Hierarchy

EngineerManagerTellerForeign

customerAccountholder

Services

Order chequesSend messageTransaction listOrder statementTransfer funds

Customer Bank staff

All VPs

Services

Query balanceWithdraw cash


Viewpoint Documentation VORD Standard Forms

Viewpoint template Service templateReference: The viewpoint name. Reference: The service name.Attributes: Attributes providing

viewpoint information.Rationale: Reason why the service is

provided.Events: A reference to a set of event

scenarios describing howthe system reacts toviewpoint events.

Specification: Reference to a list of servicespecifications. These maybe expressed in differentnotations.

Services A reference to a set ofservice descriptions.

Viewpoints: List of viewpoint namesreceiving the service.

Sub-VPs: The names of sub-viewpoints.

Non-functionalrequirements:

Reference to a set of non -functional requirementswhich constrain the service.

Provider: Reference to a list of systemobjects which provide theservice.


Viewpoint Documentation Customer/Cash Withdrawal VOID Templates

Customer

Account numberPINStart transactionSelect serviceCanceltransactionEnd transaction

Cash withdrawalBalance enquiry

Account holderForeigncustomer

Reference:

Attributes:

Events:

Services:

Sub-VPs:

Cash withdrawal

To improve customer serviceand reduce paperwork

Users choose this service bypressing the cash withdrawalbutton. They then enter theamount required. This isconfirmed and, if funds allow,the balance is delivered.

Customer

Deliver cash within 1 minuteof amount being confirmed

Filled in later

Reference:

Rationale:

Specification:

VPs:

Non-funct.requirements:

Provider:


Viewpoint DocumentationVOID Data/Control

Start transactionCancel transactionEnd transactionSelect service

Card detailsPINAmount requiredMessage

Control input Data inputACCOUNTHOLDER



Negotiation

3 Major Steps In Negotiating Requirements

1. Identify the key stakeholders

These are the people who will be involved in the negotiation

2. Determine each of the stakeholders “win conditions”

Win conditions are not always obvious

3. Negotiate

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


Elaboration

Elaboration - create an analysis model that identifies data, function and behavioral requirements

We have already examined, briefly, a number of different models.

Requirements Engineering – Elaboration

Building the Analysis Model

Elements of the analysis model

Scenario-based elements

Functional - processing narratives for software functions

Use-case - descriptions of the interaction between an “actor” and the system

Class-based elements

Implied by scenarios

Behavioral elements

State diagram

Flow-oriented elements

Data flow diagram

Requirements Engineering

Scenarios

ScenariosHelp To Describe Exceptions

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

Scenarios map nicely to Use-Case Diagrams

Exception Description Problem In Most Structured Methods

Most Structured Scenarios Methods do not include facilities for Describing Exceptions

In the ATM example, exceptions are

Timeout. Customer fails to enter a PIN within the allowed time limit

Invalid Card. The card is not recognised and is returned

Stolen Card. The card has been registered as stolen and is retained by the machine

Scenario Descriptions & Inclusions

System State at the Beginning of the scenario

Normal Flow of Events in the scenario

What can go wrong and how this is handled [Early

Risk Analysis]

Other Concurrent Activities

System State on Completion of the scenario

Event Scenarios

Event scenarios are used to describe how a system responds to the occurrence of some particular event such as ‘start transaction’

VORD includes a Diagrammatic Convention for Event Scenarios.

A. Data Provided & Delivered

B. Control Information

C. Exception Processing

D. The Next Expected Event

Validate user

Request PIN

Selectservice

Timeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Accountnumber

PIN

Accountnumber

Valid card

User OK

Event Scenario - Start Transaction VORD Diagrammatic Convention

Validate user

Request PIN

Selectservice

Timeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Accountnumber

PIN

Accountnumber

Valid card

User OK

You Need Know No Specifics This Diagram

Scenario Notation #1 Data & Control Analysis

Ellipses. data provided from or delivered to a viewpoint

Control information enters and leaves at the top of each box

Scenario Notation #2 Data & Control Analysis

Data leaves from the right of each box

Exceptions are shown at the bottom of each box

Name of next event is in box with thick edges

Use Cases #1Object Oriented Notations

Use-Cases are a scenario based technique in the UML which identify the Actors in an interaction and which describe the interaction itself

Teachers?

UML is an acronym for ?

Unified Modelling Language

Your Group May Have Different Names For The Actors – OK If Descriptive


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

Use–Cases have become a fundamental feature of UMLIntroduced by Jacobson in 1993

The Stick Figures Are Called ______________________Actors

The Ellipses Represent __________________________Interactions


The Stick Figures Are Called ______________________Actors

The Ellipses Represent __________________________Interactions

Library Use-Cases

Catalogue ManagementUML Sequence Diagram

Bookshop:Supplier

Cataloguer:Library Staff

Item:Library Item

Books:Catalog

Acquire New

Catalog Item

Uncatalog Item

Dispose

What Are The Objects?

Who Are The Actors?

The Sequence Of Actions Is From The Top To The Bottom

Use-Cases

A collection of user scenarios that describe the thread of usage of a system

Each scenario is described from the point-of-view of an “actor” - a person or device that interacts with the software in some way

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 extensions 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?

Use-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors


Class Diagram

Sensor

name/id type location area characteristics

identify() enable() disable() reconfigure()

From the From the SafeHomeSafeHome system … system …


State Diagram

Figure 7.6 Preliminary UML state diagram for a photocopier

Initialization

system status=“not ready” display msg = “please wait” display status = blinking

entry/ switch machine on do: run diagnostics do: initiate all subsystems

turn copier “on“

subsystems ready system status=“Ready”

display msg = “enter cmd” display status = steady

entry/ subsystems ready do: poll user input panel do: read user input do: interpret user input

Readingcommands

system status=“Copying” display msg= “copy count =” display message=#copies display status= steady

entry/ start copies do: manage copying do: monitor paper tray do: monitor paper flow

Making copies

start copies

system status=“Jammed” display msg= “paper jam” display message=location display status= blinking

entry/ paper jammed do: determine location do: provide corrective msg. do: interrupt making copies

problem diagnosis

paper jammed

system status=“load paper” display msg= “load paper” display status= blinking

entry/ paper empty do: lower paper tray do: monitor fill switch do: raise paper tray

load paper

paper tray empty

not jammed

paper full

turn copier “off”

not jammed

copies complete


The Specification/Requirements

Document

The Specifications/Requirements Document

Specification - can be any one (or more) of the following:

A written document

A set of models

A formal mathematical

A collection of user scenarios (use-cases)

A prototype

Requirements Engineering2 Post-Analysis & Design Processes

Validation

Requirements Engineering – Validation5 Major Things Validation Attempts To Determine

Validation - a review mechanism that looks for

1. Errors in content or interpretation

2. Areas where clarification may be required

3. Missing Information

4. Inconsistencies (a major problem when large products or systems are engineered)

5. Conflicting or Unrealistic (unachievable) requirements.

Requirements Validation

Validation is concerned with demonstrating that the requirements define the system that 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

9 Validating Requirements Guidelines - 1

1. Is each requirement consistent with the overall objective for the system/product?

2. Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

3. Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

4. Is each requirement bounded and unambiguous?

5. Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Who wanted it?

6. Do any requirements conflict with other requirements?

7. Is each requirement achievable in the technical environment that will house the system or product?

8. Is each requirement testable, once implemented?

9. Does the requirements model properly reflect the information, function and behaviour of the system to be built.

9 Validating Requirements Guidelines - 2

5 Abreviated Validation Requirements Check Points

Validity. Does the system provide the functions which best support the customer’s 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?

Requirements Validation Techniques

Requirements Reviews

• Systematic manual analysis of the requirements

Prototyping

• Using an executable model of the system to check requirements.

Test-Case Generation

• Developing tests for requirements to check testability

Automated Consistency Analysis

• Checking the consistency of a structured requirements description

Requirements Validation 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

During A Review, Each Requirement Should Be Checked For Verifiability, Comprehensibility, Traceability, & Adaptability

1. Verifiability. Is the requirement realistically testable?

2. Comprehensibility. Is the requirement properly understood?

3. Traceability. Is the origin of the requirement clearly stated?

4. Adaptability. Can the requirement be changed without a large impact on other requirements?

Requirements Engineering2 Post-Analysis & Design Processes

RequirementsManagement

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

Requirements Change Examples

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

Enduring & Volatile Requirements

Enduring Requirements. Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

Volatile Requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy

Requirements Management Planning Managing Change Of Requirements

Requirements Identification

• How requirements are individually identified

A Change Management Process

• The process followed when analyzing a requirements change

Traceability Policies

• The amount of information about requirements relationships that is maintained

CASE Tool Support

• The tool support required to help manage requirements change

Requirements Traceability

Requirements Traceability is concerned with the relationships between requirements, their sources and the system design

Source Traceability

Links from requirements to stakeholders who proposed these requirements

Requirements Traceability

Links between dependent requirements

Design Traceability

Links from the requirements to the design

A Traceability MatrixAvailable In Some CASE Tools

Requirements Change Management3 Most Common Change Stages

Should apply to all proposed changes to the requirements

The 3 Most Common Change Stages

1. Problem Analysis. Discuss requirements problem and propose change

2. Change Analysis & Costing. Assess effects of change on other requirements

3. Change Implementation. Modify requirements document and other documents to reflect change

Requirements Change Management Flow

Changeimplementation

Change analysisand costing

Problem analysis andchange specification

Identifiedproblem

Revisedrequirements

Requirement ElicitationProblems

5 Problems Of Requirements Analysis

Stakeholders don’t know what they really want or need

Stakeholders express requirements in their own terms

Different stakeholders may have conflicting requirements

Organizational and political factors may influence the system requirements

The requirements change during the analysis process. New stakeholders may emerge and the business environment change

Software EngineeringCSCI 3342

Dr. Thomas E. HicksComputer Science Department

Trinity University

Textbook: Software EngineeringBy Roger Pressman

Textbook: Software EngineeringBy Ian Sommerville

Special Thanks To WCB/McGraw-Hill & Addison Wesley For Providing Graphics Of Some Of Text Book Figures For Use In This

Presentation.

Date post:	01-Jan-2016
Category:	Documents
Upload:	ciaran-adams
View:	16 times
Download:	0 times

Dr. Thomas Hicks Computer Science Department Trinity University

Documents