1

SOFTWARERequirements Engineering

CP7007

Prof.Dr. B.Chandramouli

2

SOFTWARE REQUIREMENTS ENGINEERING

UNIT I DOMAIN UNDERSTANDING

UNIT II REQUIREMENTS ELICITATION

UNIT III FUNCTIONAL REQUIREMENTS

UNIT IV QUALITY ATTRIBUTES

AND USER EXPERIENCE

UNIT V MANAGING REQUIREMENTS

3

Syllabus Unit I

DOMAIN UNDERSTANDING Introduction

Types of requirements

Requirements engineering process

Validating requirements

Requirements and design

Requirements and test cases

Introduction to business domain – Problem analysis – Fish bone diagram – Business requirements – Business process modeling – Business use cases – Business modeling notations

UML Activity diagrams

4

The Requirements Problem: Standish Report, 1995

Survey of 350 US companies, 8000 projects8000 projects

(partial success = partial functionalities, excessive costs, big delays)

Major source of failure: poor requirements engineering 50% responses

5

The Requirements Problem: European Survey, 1996

Coverage: 3800 EUR organizations, 17 countries

Main software problems perceived to be in...

– requirements specification

> 50% responses

– requirements evolution management

50% responses

[European Software Institute, 1996]

6

Domain Understanding

Studying the system-as-is– Business organization: structure, dependencies, strategic

objectives, policies, workflows, operational procedures, ...– Application domain: concepts, objectives, tasks,

constraints, regulations, ...

– Strengths & weaknesses of the system-as-is

Identifying the system stakeholdersstakeholders:– Groups or individuals affected by the system-to-be, who

may influence its elaboration and its acceptance– Decision makers, managers, domain experts, users,

clients, subcontractors, analysts, developers, ...

ProductsProducts: Initial sections for preliminary draft proposal Glossary of terms

7

IntroductionIntroductionto Fundamentals of REto Fundamentals of RE

8

Definition

What is Requirements Engineering (RE) ?

– The problem world & the machine solution

– The scope of RE: the WHY, WHAT and WHO dimensions

– Types of statements involved: descriptive vs. prescriptive

– Categories of requirements: functional vs. non-functional

– The requirements lifecycle: actors, processes, products

– Target qualities and defects to avoid

– Types of software projects ( Green field, Single product, Multiple

line product, Inhouse, Outsourced, Customer driven, market

driven etc..)

– Requirements in the software lifecycle

– Relationship to other disciplines

9

Fundamentals of RE: outline

start

ElicitationElicitation

alternative options

agreedrequirements

documented requirements

consolidatedrequirements

RE products and processes

10

Fundamentals of RE: outline

start

Elicitation EvaluationEvaluation

alternative options

agreedrequirements

documented requirements

consolidatedrequirements

RE products and processes

11

Fundamentals of RE: outline

start

Elicitation Evaluation

alternative options

agreedrequirements

documented requirements

consolidatedrequirements

SpecificationSpecification

RE products and processes

12

Fundamentals of RE: outline

start

Elicitation Evaluation

alternative options

agreedrequirements

documented requirements

consolidatedrequirements

SpecificationQuality assuranceQuality assurance

RE products and processes

13

Fundamentals of RE: outline

start

Elicitation Evaluation

alternative options

agreedrequirements

documented requirements

consolidatedrequirements

SpecificationQuality assurance

RE products and processes

14

Fundamentals of RE: outline

start

Unit2: Elicitation

Unit 2:Evaluation

alternative options

agreedrequirements

documented requirements

consolidatedrequirements

Unit 3: Specification

Unit 4:Quality assurance

RE products and processes

Unit 5: Evolution management

15

RE: A Preliminary Definition

CoordinatedCoordinated set of activitiesactivities ...

– for exploringexploring, evaluatingevaluating, documentingdocumenting, consolidatingconsolidating,

revisingrevising and adaptingadapting the objectivesobjectives, capabilitiescapabilities,

qualitiesqualities, constraintsconstraints & assumptionsassumptions on a software-

intensive systemsystem

– based on problemsproblems raised by the system-as-isas-is and

opportunitiesopportunities provided by new technologies

16

The Scope of RE: the WHY, WHAT, WHO Dimensions

ObjectivesWHYWHY

a new system?

WHATWHAT services?

WHOWHO will be

responsiblefor what ?

satisfy

assignment

requirements, constraints,assumptions

problems, problems, opportunities,opportunities,

system knowledgesystem knowledge

System-to-beSystem-as-is

17

Requirements in the Software Lifecycle

RequirementsDocument

Project estimations(size, cost, schedules)

Project workplan

Software prototype,mockup

Follow-up directives

Software architecture

Call for tenders,proposal evaluation

Quality Assurancechecklists

Project contract

Software evolutiondirectives

Software documentation

Acceptance test data

Implementationdirectives

User manual

RE, system design & software architecture design are inevitably intertwined

The RD impacts on many software artifacts

18

The requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

19

19

Requirements Engineering Activities

Feasibility studyDetermine if the user needs can be satisfied with the available technology and budget.

Requirements analysis

Find out what system stakeholders require from the system.

Requirements definition

Define the requirements in a form understandable to the customer.

Requirements specification

Define the requirements in detail. (Written as a contract between client and contractor.)

20

Problems of Requirements Analysis

Various problems typically arise:

– Stakeholders don’t 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.

21

The Requirements Analysis Process

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry

22

Categories of Requirements

Functional requirements: Functional requirements: prescribe what services the software-to-be should provide

– capture intended software effects on environment, applicability conditions

– units of functionality resulting from software operations

“The software shall control the acceleration of all trains”

Non-functional requirements: Non-functional requirements: constrain how such services should be provided

– QualityQuality requirements: safety, security, accuracy, time/space performance, usability, ...

– Others: compliance, architectural, development reqs

– To be made precise in system-specific terms

“Acceleration commands shall be issued every 3 seconds to every train”

23

Types of Non-functional Requirements

Performancerequirements

Spacerequirements

Usabilityrequirements

Ef ficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

24

Requirements Validation

Requirements must be written so that they can be objectively validated and verified.

Imprecise:– The system should be easy to use by experienced

controllers and should be organised in such a way that user errors are minimised.Terms like “easy to use” and “errors shall be minimised” are useless as specifications.

Verifiable:– Experienced controllers should be able to use all the

system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.

25

Precise Requirements Measures (I)

Property Measure

SpeedProcessed transactions/secondUser/Event response timeScreen refresh time

Size K Bytes; Number of RAM chips

Ease of useTraining timeRate of errors made by trained usersNumber of help frames

26

Precise Requirements Measures (II)

Property Measure

ReliabilityMean time to failureProbability of unavailabilityRate of failure occurrence

RobustnessTime to restart after failurePercentage of events causing failureProbability of data corruption on failure

PortabilityPercentage of target dependent statementsNumber of target systems

27

Requirements To Design

A requirements specification defines what the customer wants

A design specification defines how you satisfy what the customer wants.

– To go from step 1 to 2

First step is analysis and elicitation - to study the problem of input and output requirements carefully to make sure they are understood and make sense

Design starts with pictorially (UML) represent the analysis

28

Requirements To Design

Use case: list of the user actions and system responses for a particular sub-problem in the order that they are likely to occur

Sequence diagram: shows all the objects involved in this use case across the horizontal axis, time is shown along the vertical axis

Class diagram

Component diagram

Activity diagram

State Transition diagram

Precondition: a statement of any assumptions or constraints on the method data before the method begins execution

Postcondition: a statement that describes the result of executing a method

29

Requirements To Design

– UML diagrams are a design tool to illustrate the interactions between

• Classes

• Classes and external entities

– For better understanding Abstraction, Refining are used

– For better data design Inheritance, Information Hiding are used

– For better structure design Modularity, Architecture are used

30

Requirements to Testing - Traceability

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;

31

CASE tool support

Requirements storage– Requirements should be managed in a secure, managed

data store.

Change management– The process of change management is a workflow process

whose stages can be defined and information flow between these stages partially automated.

Traceability management– Automated retrieval of the links between requirements.

32

Business Domain

3333

Background

A key component of Business Modeling (Domain Analysis) - in addition to Business Use Case Model and Business Object Model and other artifacts - is the Domain Model– Recall the Business Model is not only a graphical model, but

also other artifacts such as the Business Vision, Business Rules, Business Glossary, Business Risk List, and the Domain Model.

– All relate to the enterprise / organization.

– The Domain Model contains Key Abstractions (business / technology)– Is a Visual Model of business entities, relationships, multiplicities, and

more.

Prior to embarking on gathering requirements and capturing them via Use Cases (application use cases, requirements use cases, that is…), we need to understand the key entities in the business domain.

343

Domain Modeling - an Introduction

Domain Modeling is the task of discovering “objects” (classes, actually) that represent those business entities and concepts.

Recognize that the domain model will be a superset of your entity classes needed for your application development.– These class diagrams – later on - will likely contain some of the

entities found in your domain model.

– These appear similar to ERDs, but they are not the same.

• Fully-attributed list (not a schema or physical database design…)

3535

Domain Modeling - continued

Domain Models sometimes considered ‘informal’ class diagrams.

Developed as part of domain analysis (business modeling)

The ‘classes’ (entities) represent what you have learned about various ‘things’ (entities) and relationships between/among them in the business domain itself.

As a Visual Model, this model helps in understanding the domain.

Also serves as a Glossary, in that the entities will contain attributes and other defining qualities.– Think ‘Customer, ’ ‘Product Line’ etc.

3636

Domain Modeling - continued

The Domain Model: – Does NOT wholly support requirements analysis (ahead).– Is not INTENDED to…– Addresses entities in the domain of the organization –

that may be quite apart (superset) from a computer application that may use them.

– Are normally not concerned with representations of • inheritance, • polymorphism, etc, but can show aggregation,

multiplicities, etc.• (as we would be when embarking on development of an

application.)

3737

Domain Modeling - continued

In requirements analysis – – as part of gathering information on the application to

be developed,

– we develop class diagrams - contain entities (classes) taken from the domain model.

But the class diagrams (for development) will represent data that will be stored and manipulated by the application.

3838

Domain Modeling - continued

Models produced as part of requirements analysis (ahead lectures) will contain:

– Entity classes – • some may be derived from Domain Model,

– Boundary classes – • used for the user interface and external system interfaces

– Control Classes • used for controlling logic and business rules, and, in

general, orchestrating the application functions.

3939

So, what do we do?

Doing domain modeling is very important. Don’t want to spend too much time trying to model

everything!!! Yet we need to have a good starting point for requirements

analysis to solve the ‘problem.’

So, our domain modeling approach is to develop an ‘initial’ set of business entities (nouns).

This is a a static model of the domain by finding appropriate entities that represent the real key abstractions in the domain.– A ‘key abstraction’ example is Customer, Product, Account,

etc. – Serve to underpin system development later.

400

Developing Entities for Domain Model

Sources (again) of Domain Knowledge. Here are a few:– Interviews– Questionnaires– Quarterly Reports– Mission Statements– Subject Matter Experts (SMEs)– Newsletters– Web pages– A company’s e-business….

Look for nouns in these sources! – these are candidate classes in the domain model.– More examples: Menu, Customer, Food order, Payment, On-line order…

Things!

– Customer (class with attributes) ‘orders’ (relationship) Food (class with attributes)

– Capture graphically! – ‘Customer’ and ‘Food’ are entities related by ‘Orders’ with

multiplicity 1..n.

411

Developing Domain Entities

Read sources very closely; Capture these ‘nouns’ and noun phrases. Look for the ‘things’ in the domain…

Possessive phrases generally indicate that the nouns should be attributes rather than objects. – Try to identify attributes but omit operations.

Build associations (and name them) between domain entities Add multiplicities carefully Don’t worry about aggregations and association classes and much

more unless these relationships are clearly evident.

Model in some tool.

42

Problem-Analysis-Modeling

- Requirements analysis

- Flow-oriented modeling

- Scenario-based modeling

- Class-based modeling

- Behavioral modeling

’005

43 3

Goals of Analysis Modeling

Provides the first technical representation of a system

Is easy to understand and maintain

Deals with the problem of size by partitioning the system

Uses graphics whenever possible

Differentiates between essential information versus implementation information

Helps in the tracking and evaluation of interfaces

Provides tools other than narrative text to describe software logic and policy

44

A Set of Models

Flow-oriented modeling – provides an indication of how data objects are transformed by a set of processing functions

Scenario-based modeling – represents the system from the user's point of view

Class-based modeling – defines objects, attributes, and relationships

Behavioral modeling – depicts the states of the classes and the impact of events on these states

45

Requirements Analysis

46 6

Purpose

Specifies the software's operational characteristics Indicates the software's interfaces with other system

elements Establishes constraints that the software must meet Provides the software designer with a representation of

information, function, and behavior– This is later translated into architectural, interface,

class/data and component-level designs

Provides the developer and customer with the means to assess quality once the software is built

47 7

Overall Objectives

Three primary objectives– To describe what the customer requires– To establish a basis for the creation of a software design– To define a set of requirements that can be validated once

the software is built

All elements of an analysis model are directly traceable to parts of the design model, and some parts overlap

48 8

Analysis Rules of Thumb

The analysis model should focus on requirements that are visible within the problem or business domain – The level of abstraction should be relatively high

Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the following– Information domain, function, and behavior of the system

The model should delay the consideration of infrastructure and other non-functional models until the design phase– First complete the analysis of the problem domain

The model should minimize coupling throughout the system– Reduce the level of interconnectedness among functions and classes

The model should provide value to all stakeholders The model should be kept as simple as can be

49 9

Domain Analysis

Definition– The identification, analysis, and specification of common, reusable capabilities within a specific application domain– Do this in terms of common objects, classes, subassemblies, and frameworks

Sources of domain knowledge– Technical literature– Existing applications– Customer surveys and expert advice– Current/future requirements

Outcome of domain analysis– Class taxonomies– Reuse standards– Functional and behavioral models– Domain languages

50 50

Analysis Modeling Approaches

Structured analysis– Considers data and the processes that transform the data as

separate entities

– Data is modeled in terms of only attributes and relationships (but no operations)

– Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data

Object-oriented analysis– Focuses on the definition of classes and the manner in which they

collaborate with one another to fulfill customer requirements

51

Fishbone diagram

Cause – effect diagram

Ishikawa diagram

52

53

54

Business Process and management

Business Process : A set of logically related tasks performed to achieve a defined business outcome

Business Process Management(or BPM) refers to activities performed by organizations to manage and, if necessary, to improve their business processes

55

Business Process Management Notation

Business Process Modeling Notation (BPMN) is a graphical notation that describes the logic of steps in a business process

Why is it important to model with BPMN?

• BPMN is an internationally accepted process modeling standard.

• BPMN is independent of any process modeling methodology.

• BPMN creates a standardized bridge which reduces the gap between business processes and their implementation.

• BPMN enables you to model processes in a unified and standardized way so that everyone in an organization can understand each other

56

BPMN - TASK

Task: A task is carried out when the work in the process is not broken down into more detail. It is executed by one person and/or one application.

57

BPMN – Sub Process

Subprocess: A Subprocess is a compound activity included in a process. It is compound because it includes a series of activities and a logical sequence (process) indicating that it can be analyzed in more detail. Visually it can be “collapsed” or “expanded

58

59

Unified Modeling Language

A visual modeling language A standardized general-purpose modeling

language in the field of software engineering. Used to specify, visualize, construct and

document the artifacts of an object-oriented

software -intensive system under development A set of 9 diagrams (UML 1.4) and 13 diagrams

(UML 2.0) Not an industry standard but used widely

60

UML

Is not a S/W development methodologies

– Descriptive not prescriptive • Combines best practices from

• Data modeling (ex: ER diagram)• Business modeling (ex: Workflows)• Object modeling, and• Component modeling

• Combines• Booch method (G Booch)• OMT – Object modeling Techniques (J Rumbaugh)• OOSE (E Jacobson)

• An extensible language– Stereotypes, profiles

61

UML Users

• Architect

• Domain expert

• Designer

• Programmer/Developer

• Instructor

62

UML 2.0 Diagrams

63

Important UML Diagrams

64

Lets Discuss

• Use Case Diagram ( represents a Functional model ) Describes the functionality from user point of view)

• Sequence Diagram Describes the internal behavior as a sequence of messages

exchanged between a set of objects

• Statechart Describes the behavior in terms of states of individual objects and

its transitions

• Activity Diagram Describes the system behavior in terms of sequence of activities

• Class Diagram ( represents a Object model ) Describes the structure of the system in terms of objects, attributes,

associations and operations

65

Use cases

Define system functional requirements in terms of Actors and Use cases– Each use case specify a piece of functionality– A use case can be elaborated in terms of sequence

of interactions between Actor and the domain objects

– Simple use cases may involve only one interaction– More complicated use cases may involve several

interactions

66

Example: Use case Diagram

67

Sequence Diagram

Shows sequence of object interactions in a use case Emphasis on messages passed between objects

– Objects represented by vertical lines

- Actor is on extreme left of page

– Messages represented by labeled horizontal arrows

- Only source and destination of arrow are relevant

- Message is sent from sending object to receiving object

– Time increases from top of page to bottom– Spacing between messages is not relevant– Message sequence numbering is optional

68

Example: Sequence Diagram

69

State Chart

Graphical representation of finite state machine

States are rounded boxes Transitions are arcs State chart relates events and states

– Event– Causes change of state– Referred to as state transition

State represents interval between successive events

Initial state– Arc with black ball at end

70

Example: State Charts

71

Activity Diagram

Models a process workflow

Different from State chart

(A State chart models states of an object)

Models concurrency and synchronization

Models normal and alternate flow of

control in the same diagram

• Can be combined with a state chart

72

Example: Activity Diagram

73

Class Diagram

Objects and Classes

Objects represent “things” in real world– Provide understanding of real world– Form basis for a software solution

An Object is a single “thing”– E.g., John’s car , – Mary’s account etc..

A Class (object class) is a “blue print” of

objects with the same (similar) characteristics

– E.g., account, employee, car, customer

Each object has an identity and is distinguishable from others in the class

74

Example: Class Diagram

75

One case study

End of Unit 1