RequirementsEngineering

Indri Sudanawati Rozas

April 2012

Activities?

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Requirements analysis• Sometimes called requirements elicitation or

requirements discovery• Involves technical staff working with

customers to find out about the application domain, the services that the system should provide and the system’s operational constraints

• May involve stakeholders: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.

Requirements Analysis

• Acquire understanding about the problem domain characteristics and problem to find the solution

• It is an information-acquiring, -collating, and –structuring process through which one attempts to understand all the various parts of a problem and their relationships.

• Basic Issues:– How to effectively elicit a complete set of requirements

from the customer or other sources?– How to decompose the problem into intellectually

manageable pieces?– How to organize the information so it can be understood?– How to communicate about the problem with all the parties

involved?– How to resolve conflicting needs?– Ho to know when to stop?

Analysis PrinciplesEach analysis method has a unique point of view.

All analysis methods are related by a set of operational principles:• represent and understand the information domain• define the functions that the software• represent the behavior of the software• use models to depict information, function, and behavior

--> uncover the details in a layered fashion.• move from essential information toward to details

A set of guidelines for requirement engineering:•understand the problem before beginning to create the analysis model•develop prototypes to help user to understand how human-machine interactions•record the origin of and the reasons for every requirement•use multiple views of requirements•prioritize requirements• work to eliminate ambiguity

The Information Domain• Software is built to process data, to transform data from one

form to another.

• Software also process events.

• The first operational analysis principle requires to exam the information domain.

• Information domain contains three different views of the data and control:

– information content and relationship:

information content --> represent the individual data and control objects– information flow:

represents the manner in which data and control change as each moves through a system. Data and control moves between two transformations (functions)

– information structure:

represent the internal organization of various data and control items• data tree structure• data table (n-dimension)

The requirements analysis process

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry

System models

• Different models may be produced during the requirements analysis activity

• Requirements analysis may involve three structuring activities which result in these different models– Partitioning. Identifies the structural (part-of)

relationships between entities– Abstraction. Identifies generalities among

entities– Projection. Identifies different ways of looking at

a problem• Using modeling techniques, e.g. UML

System Requirements Analysis Consideration

http://www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf

Requirements AnalysisFundamental Techniques (Views)• functional view

– hierarchy - function tree– process use cases– information ow data flow diagram (DFD)

• data oriented view– data structures data dictionary (DD), syntax diagram, Jackson diagram– relations between entities entity relationship diagram (ER)

• object-oriented view– class structure class diagram

• algorithmic view– control structures– pseudo code, structogram, flow diagram, Jackson diagram– conditions rules, decision table

• state-oriented view– state machines– Petri nets– sequence charts

Methods for Requirements Analysis

1. Structured Analysis

2. Object Oriented Analysis

3. Problem Domain Oriented Analysis

4. Viewpoint Oriented Analysis

1. Structured Analysis

• Centered upon modeling the pre-existing system

– Process

– Data flow

– Structure of data stored

• Weakness:

– Downplay the study of the problem domain

– Requirements are specified in term of design

– Lack of sharp boundary between analysis and design encourage premature design

– Functional specification is absent

– Ill-suited for certain (not rarely) types of application

2. Object Oriented Analysis

• It’s not really an analysis:– It requires pre-existing requirements document

and behaviour specification.• High-level, architectural, design of the solution

system. • OOA Outline:

– Identify object classes within the problem domain

– Define the attribute and methods of those classes

– Define the behaviour of those classses– Model the relationships between those classes

2. Object Oriented Analysis

• Three perspective of class model– Specification (i.e. interface classes)– Conceptual (i.e. problem domain classes

– related to analysis)– Implementation (i.e. related to internal

design)

3. Problem Domain Oriented Analysis

• Centered on modeling the problem context– Problem frames: capture significantly more

information about the problem domain• Less modeling, more description, procedure:

– Collect basic information and develop problem frame(s) to establish the type of the problem domain

– Collect further detail and develop description of the relevant characteristics of the problem domain

– Collect and document the requirements for the new system

• Type of problem domain:– Workpiece system – perform directed operations upon

objects that exist only within the system – Control system – control the behavior (required-

commanded) of part of the problem domain – Information system – provide information (automatically-

responsively) about the problem domain– Transformation system – transform input data in a

particular format into output data in a corresponding, particular format

– Connection system – maintain correspondence between sub-domains that are not directly connected

3. Problem Domain Oriented Analysis

4. Viewpoint-oriented analysis

• Stakeholders represent different ways of looking at a problem or problem viewpoints– different types of stakeholders– different views among stakeholders of same type

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

Multiple problem viewpoints

Problemto be

analysed

Requirements vs. Design

RequirementsRequirements DesignDesign

Describe Describe whatwhat will be deliveredwill be delivered Describe Describe howhow it will be done it will be done

Primary goal of analysis:Primary goal of analysis:

UNDERSTANDINGUNDERSTANDING

Primary goal of design:Primary goal of design:

OPTIMIZATIONOPTIMIZATION

There is There is more than one more than one solutionsolution There is There is only one only one (final) solution(final) solution

Customer interestedCustomer interested Customer not interested (Most of Customer not interested (Most of the time) except for externalthe time) except for external